How to Handle Data Persistence In Domain Driven Design

Now when it comes to Domain Driven Design, the goal is to have both data and behavior encapsulated in a single entity (the model class)

I would challenge this. If you have your Models as data structs and put the logic in "Domain Services" then all your problems (from this question) will be solved.

The structure will be something like

App
   Construct Repository
   Construct Business Logic Service
   Loop Over things to do
     Fetch Model from Repo
     Call Logic, passing in Model Model
     Save model back to Repo

If you have this, but then want a more object orientated approach, you can just move the code blocks around to get:

App
   Construct DTO->Model and back Mapper
   Construct Repository, passing in Mapper
   Loop Over things to do
     Fetch Model from Repo
     Call Model.Logic
     Save Model back to Repo

You'll find the code is pretty much identical, You've just moved it into different objects.

The problem with this style, happens when you have more than one logical operation. The you have to either put both on the same Model, or start having Model versions for each Bounded Context. Rather than just having a Logic Service class per operation.

Problem 1 and 3 are solved by having the DTO mapper hidden inside the repository. This separates the Model from the ORM, although this should be possible to do with the correct setup in most ORMS without an extra mapper.

Models should have all the data for the aggregate in them, so you can perform operations purely in memory without recourse to the database. So you should never have problem 4

This should also help you with problem 2. As you have all the data in the Model, there should be no need to inject a repo into your Model or Logic

Now when it comes to Domain Driven Design, the goal is to have both data and behavior encapsulated in a single entity (the model class)

Yeah, this is essentially correct; when you separate "data" from "behavior", then people begin to complain that you have an anemic domain model, aka "you're doing it wrong".

As far as I can tell, there aren't any good answers to the persistence question, just a number of kind of ok answers with different trade-offs.

The most "straight forward" approach would be to use something like the Memento pattern from the Design Patterns book (Gamma et al).

after = Factory.create( before.memento() )
assert after.isInSameStateAs(before)

Which is to say, you get information out of your entities via a query that produces an immutable VALUE OBJECT, and then you solve the problem of how to persist that (aka kick the can down the road). Now, in the design patterns book, the memento is typically opaque (ie bytes), but there's no particular reason that it couldn't instead be a "document" or a "message" or a "record", with affordances that allow you to get the information you need out of it.

A variation of this that allows you to shuffle some of the dependencies around is to use a builder interface

after = Factory.create( before.memento(builder) )
assert after.isInSameStateAs(before)

In effect, you define a protocol that allows the entity to pass information, and then choose the appropriate implementation .

If you look at dddsample-core (an open source DDD demonstration piece originally built in collaboration with Eric Evans's company), you can see that they "just" couple their models to their (current) persistence strategy.

public interface CargoRepositoryJPA extends org.springframework.data.repository.CrudRepository<Cargo, Long>, CargoRepository

and the Cargo entity has a bunch of jakarta.persistence annotations.

In some designs, you can combine these in a slightly different way; instead of passing around some opaque thing that only the model understands, you can store in the model an opaque thing that only the persistence strategy understands.

class Cargo<OpaqueHandle> {
   OpaqueHandle opaqueHandle

   <T> T storeIt( StorageProtocol<OpaqueHandle, T> protocol ) {
      return protocol.withHandle(this.opaqueHandle)....;
   }

The way you might use this is that your persistence uses an O/RM to fetch an anemic entity, and you read information out of it -- passing the reference to the anemic entity as a "memento" that the Cargo domain model carries around, and then at persistence time your storage protocol gets a handle to that entity back (along with the domain information we care about remembering) and now you "dirty" the O/RM entity by copying information into it, and then saving it.

Another variation (and I never see this one outside of my own experiments) comes from recognizing that your "domain logic" usually can be written independently of your internal data representation, so you separate them -- your domain logic goes into an abstract class that expresses the rules, and has place holders for the data affordances. What your persistence code actually gives you is a derived class, with a specific data model suitable for persistence and affordances that give the domain logic read/write access to the data model.

If you are feeling very fancy, you could implement your domain logic using traits, rather than an abstract class.

And then there are those who take the position that the entities rfc::2119::SHOULD be anemic, because their single responsibility is manipulating the data model (in the same way that a map or list is responsible for manipulating some internal data structure) and therefore shouldn't also be responsible for domain logic (which changes for completely unrelated reasons).