DDD approach to basic CRUD operations in a complex domain-centric application

Question

My company is rewriting our web application from scratch. It's a large enterprise level application with a complex domain in the finance industry.

We are using an ORM (Entity framework) for persistence.

In essence, half of our application centers around gathering raw data from the user, storing it, and then the other half of the application that contains most of our actual domain logic takes that raw data to create our domain picture which differs greatly from those original raw inputs, and passes it into a calc engine, runs calcs, and spits out results, which are then displayed to the user.

In a DDD approach using layers, it seems like CRUD operations go through the domain layer. but at least in our case, this doesn't seem to make sense.

When a user goes to the edit screen to change an investment account for instance, the fields on the screen are the exact fields stored in the database, not the domain representation used later for calculations. So why would I load the domain representation of the investment account when the edit screen needs the database representation (raw inputs)?

After the user clicks "Done" on the investment account screen, and a POST is done to the controller, the controller now has pretty much an exact database representation of the investment account that it needs to save. But for some reason, I'm supposed to load the domain representation to make modifications instead of just mapping the controller's model directly to the database model (Entity framework model)?

So in essence I'm mapping a data model to the domain model, just so it can then be mapped back to the data model to persist. How does that make sense?

Answer 1

How does that make sense?

Short answer: it doesn't.

Longer answer: the heavyweight patterns for developing a domain model don't apply to those portions of your solution that are just a database.

Udi Dahan had an interesting observation that may help clarify this

Dahan considers that a service has to have both some sort of functionality and some data. If it does not have data, then it is just a function. If all that it does is performing CRUD operations on data, then it is database.

The point of the domain model, after all, is to ensure that all of the updates to the data maintain the current business invariant. Or, to put it another way, the domain model is responsible for ensuring that the database that acts as the system of record is correct.

When you are dealing with a CRUD system, you usually aren't the system of record for the data. The real world is the book of record, and your database is just a locally cached representation of the real world.

For instance, most information that appears in a user profile, like an email address, or a government issued identification number, has a source of truth that lives outside of your business -- it's somebody else's mail administrator that assigns and revokes email addresses, not your app. It's the government that assigns SSNs, not your app.

So you aren't normally going to be doing any domain validation on the data coming to you from the outside world; you might have checks in place to ensure that the data is well formed and properly sanitized; but its not your data - your domain model doesn't get a veto.

In a DDD approach using layers, it seems like CRUD operations go through the domain layer. but at least in our case, this doesn't seem to make sense.

That's right for the case where the database is the book of record.

Ouarzy put it this way.

Working on lots of legacy code though, I observe common mistakes to identify what is inside the domain, and what is outside.

An application can be considered CRUD only if there is no business logic around the data model. Even in this (rare) case, your data model is not your domain model. It just means that, as no business logics is involved, we don’t need any abstraction to manage it, and thus we have no domain model.

We use the domain model to manage the data that belongs inside the domain; the data from outside the domain is already managed somewhere else -- we're just caching a copy.

Greg Young uses warehouse systems as a primary illustration of solutions where the book of record is somewhere else (ie: the warehouse floor). The implementation he describes is a lot like yours -- one logical database to capture messages received from the warehouse, and then a separate logical database caching the conclusions drawn from the analysis of those messages.

So maybe we have two bounded contexts here? Each with a different model for an investment account

Maybe. I'd be reluctant to tag it as a bounded context, because it's not clear what other baggage comes along with it. It might be that you have two contexts, it might be one context with subtle differences in the ubiquitous language that you haven't picked up yet.

Possible litmus test: how many domain experts do you need; two domain experts to cover this spectrum, or just one who talks about the components in different ways? Basically, you might be able to guess how many bounded contexts you have by working Conway's law backwards.

If you consider bounded contexts to be aligned with services, it may be easier: should you be able to deploy these two pieces of functionality independently? Yes suggests two bounded contexts; but if they need to be kept synchronized, then maybe its just one.

Answer 2

Ok imagine you implement your account creation page mapping the form post directly to an EF object which is then saved to the db.

Lets further assume that the database has various restrictions that prevent completely wrong data being inputted. Accounts always have Customers etc.

Everything seems to work ok. But then the business makes a new rule.

• Accounts created on a Thursday get a 2% bonus interest rate. (assume interest rate is one of the account fields)

Now you have to put this logic somewhere and you don't have a domain object to put it in.

DDD assumes that you will always have these kind of rules, and you probably do. Creating an account must have various checks, an audit log etc its not going to just be 'write a row to the db'

Plan your domain out assuming there is no persistence or MVC controllers with extra logic in. Make sure you capture all of the requirements and they are all in the domain model.

Answer 3

In your domain you shouldn't have to know that the database even exists.

Your domain is about business rules. The stuff that needs to survive when the company that made your database goes out of business. That is, if you want your company to survive. It's really nice when those rules don't care that you've changed how you persist data.

Database details exist and need to be dealt with. They should live somewhere else. Put them across a boundary. Carefully control how you communicate across that boundary or it's not a boundary.

Uncle Bob has this to say about what to put your data in:

Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like. Or the data can simply be arguments in function calls. Or you can pack it into a hashmap, or construct it into an object.

The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows. We don’t want the data structures to have any kind of dependency that violates The Dependency Rule.

[…] when we pass data across a boundary, it is always in the form that is most convenient for the inner circle.

Clean Architecture

He also explains how your outer layers should be plugins to your inner layers so inner layers don't even know outer layers exist.

Follow something like that and you'll have a nice place to ignore the database where you can worry about input validation rules, rules that input must be persisted somehow, rules to run calculations, rules to send those results to whatever output. It's actually easier to read this kind of code.

It's either that or you decide that your domain is really just to manipulate the database. In that case your domain language is SQL. If so fine but don't expect your implementation of the business rules to survive a change in persistence. You'll end up needing to completely rewrite them.

Answer 4

Applying DDD theory:

There are two Bounded Contexts in that domain:

• The calculations of the investment account. The investment account mathematical model is one element maybe an Aggregate.
• Core Finance. The client investment account is one of the Entities.

Each Bounded Context can have a different architectural design.

Example:

The Client Investment Account is an Entity (maybe an Aggregate, depends on the domain) and the persistence of data is made via the Entity's Repository (RDB or other type of DB like an OO Database).

There is not a DDD approach to CRUD operations. To have a DB field tied to an object's data breaks design principles.