CODEWITHSUNDEEP
domain-driven-design
tlt
tlt

Reputation: 15211

Why should repository methods accept domain entity as parameter?

Lets assume we have separate read models so that we use repositories only on write side, not on read side. (and this question is all about write side)

Also, lets assume one of our goals is to have full Aggregate/Entity encapsulation in a way that they expose only behaviour and not state. (meaning, no getters/setters)

Next, lets assume we dont want to use ORMs nor reflection for getting aggregate internals from within repository.

Obviously, one of the solutions left is that aggregate itself exposes its full state as a VO/poco and hand it over to repository. Repository would then know how to map it to DAO and save it.

Now, on many places i read that repositories should accept aggregates themselves.

Question is: why? What is wrong with aggregate expose VO of its state, hand it to repository and let repo do the save based on it?

Benefit is full & clear aggregate encapsulation.

Upvotes: 0

Views: 405

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57214

What is wrong with aggregate expose VO of its state, hand it to repository and let repo do the save based on it?

That approach violates some of the other assumptions of the domain modeling idea.

One of those assumptions is that the key business logic and the "plumbing" should be separate. The fact that you need to get a serializable representation of the aggregate is an accident of the fact that you are trying to write state into a stable storage (that step would be completely unnecessary if you were keeping the aggregate cached in memory).

A second assumption is that using "objects" to model the domain is a good idea. If you were using a functional approach, then of course you would be saving values, rather than objects.

It helps, I think, to keep in mind that the context of the solutions we write has changed a lot in the last 15-20 years. Patterns that make sense for a localized application with long sessions that include many interactions don't necessarily make sense for distributed stateless applications, and vice versa.

that pattern cause you to sacrifice aggregate encapsulation

No, it doesn't - asking an object for a copy of some information in a previously agreed upon representation doesn't violate encapsulation. See Kevlin Henney, for example.

What it does do, however, is require interfaces suitable for two different collaborators: your applications, that care about the business rules, and your repository, that cares about persistence of representations.

Upvotes: 1

Related Questions