If you need to access a database to solve your particular problem, then... Well, you need to access a database. Doesn't matter what Jimmy Bogards, Eric Evans or anyone else says. If their rules don't allow you to do that, then break their rules, follow someone else's rules, or make up your own.
When you read some rule on the internet that someone has devised, try to understand the motivations behind it first, before you apply it. That way, you have a reasonable assurance that the application of said rule aligns with your own needs and expectations.
Rules like the one you cited from Eric Evans generally have one of two motivations:
- Separation of Concerns, and
Separation of Concerns mostly means "write each class or method so that it has one area of expertise and does that well." Often, that means writing some module that specializes in database access only, allowing other modules/classes to focus on their own specific concerns without being concerned with the details of data retrieval. It also means that your classes can be "persistent-ignorant," meaning they don't have to know how to save or retrieve themselves from a database, especially some specific database technology.
Decoupling, within the context of database access, generally means one of two things:
- You want to isolate data retrieval from the rest of the system, just in case you might someday change out the database implementation for something else, or
- You want to mock the data retrieval mechanism for unit testing purposes.
There are two commonly-accepted ways to access data from a database. The first way is to use CRUD operations (create, read, update, delete). The second is to provide a Business Logic Layer. A business logic layer has methods on it like
GetOffers() which provides more intelligent (and optimized) retrieval of data than create, read, update and delete.
Now then. Jimmy Bogard's Wicked Domain Models:
What is a domain model?
An object model of the domain that incorporates both behavior and data.
Why should I care?
A lot of times – you shouldn’t.
When you should – complex domain, or a long-lived project where behavior gets added piece by piece.
So even Jimmy Bogard says "use it only if you need it."
Many software developers today suffer from "Pattern-Matching disease." They think everything in software development is a pattern, and that writing a program is an exercise in stitching patterns together. Unfortunately, that's not quite the way it works, nor is slavishly following somebody's ideas about "best practices" without understanding why.