域驱动设计中值或实体类型的存储库

Question

I'm reading about Repositories in Domain Driven Design and the Microsoft patterns for micro-service architecture and they both agree that I should have one Repository per Aggregate Root. I generally agree with this, however I have a naming problem.

Aggregate is to Repository as...

Entity is to ???

Value is to ???

In my specific scenario I have a Repository for a Product object in the context of a marketing website.

Product is an Aggregate of the ProductInfo marketing information entity (Aggregate Root), List of ProductSpecs and ShippingInfo entities, along with a listing of RelatedProduct value references to other bounded contexts.

Now in my Repository I have to pull together data from different Entities and value objects to make the aggregate root.

I get the ProductInfo(root), and RelatedProducts(value) from a CMS. The ProductSpecs(entity) and ShippingInformation(entity) come from rest apis (microservices that are handling other bounded contexts).

In my first attempt I created repositories/interfaces/domain pocos for all the Entities, then had the UI layer map them to viewmodels for display. Essentially making an Aggregate per Entity, however the Entities are shaped like Data Access Objects (because at this point they are), and those concerns are leaking into my domain. If and when we depreciate the Shipping Api and migrate that into the CMS I'll have to delete and update the repositories/interfaces then go update everything in the UI layer that touches those all because I changed the location of where I was storing something.

My current attempt is to make the Aggregate a bit larger to better represent how the system is using the object rather than how it's stored, but I feel like I'm getting stuck on what to name the classes that supply the entities and values and how to architect it.

I want my CMS, and Api query logic in separate projects/dlls so they can be reused, I want a repository that combines the data access objects to create aggregates. What do I call the classes in the CMS and Api query projects? Is there a name for a pattern that I should be using?

Answer 1

The domain driven design concepts are all about the domain model and that it should be totally independent of used technologies. You can achieve this by letting your domain defining business driven interfaces with expected behavior. Your infrastructure then implements these interfaces with suitable technologies. You can find more about this strategy when searching for the inversion of control principle.

The repository pattern of Eric Evans in his DDD book is a good example for this strategy. I can only guess that he introduced the repository pattern instead of the more generic inversion of control principle, because it is the most common case of using technology for persisting objects.

For me the repository is also the factory for a very important model types, the aggregates. For this reason you should use them as described by your references taken from Microsoft. This includes that your repository is capable of giving you the root aggregate as a whole consistent unit including embedded entities and value objects.

This is the only way your root aggregates can take their responsibility to always managing a consistent state within their boundaries. Eric talks here of holding invariants.

So far so good. Now you come to an ugly part. If you model your aggregates as they suit your domain best, you will have to solve the problem of mapping the domain model to a specific database model/technology. This is called the object relational impedance mismatch. Object relational mappers (ORMs) like JPA, Hibernate, etc. should solve this for you, but the problem stays that this can be a cumbersome and tricky part.

Nonetheless you should hide all this ugly things in the repository implementation. You will need their DAOs, JEE entities, entity managers. Whatever. But you never expose them beyond the repository interface.

Last I will cover your GUI topic. Who uses the domain with all it's fine granular model elements? Normally only the application layer that formulates commands from user input and delivers views for user output. You can think of the application layer as the translator between GUI and the domain. For this reason you expose some kind of slowly changing and long term stable model to the GUI and can go in fast pace changes in your model.

Hope this helps