Domain vs Entities model? Domain-Driven-Design (DDD)?

Question

In this github, https://github.com/johnph/simple-transaction, under the Transaction.Framework project, there are entities (located at Data/Entities)

• AccountSummaryEntity.cs
• AccountTransactionEntity

and in the domain folder, there are domain model:

• AccountSummary.cs
• AccountTransaction.cs
• TransactionResult.cs

From what I observed, the entities are mainly used for repositories while the domain model is used for almost everything else like business logic validation. Is this known as domain-driven-design?

• Flater: The way you're going about this question is putting the cart before the horse. I suggest you learn what DDD is to then learn how to apply it, rather than pointing at something and asking if this might be DDD. There are several similar design philosophies that are not precisely DDD, and a lot of DDD implementations tend to make compromises for pragmatic tradeoffs. Spotting DDD in the wild is not going to be a productive way to learn about DDD.

Answer 1

It is unfortunately a popular form of DDD. I say unfortunately because it completely ignores the core principles of DDD, that is the actual modeling of the problem.

Having pure data structures does nothing to tell the reader what is happening, what problems are being solved, it does not use the Ubiquitous Language, since getting/setting stuff is rarely if ever part of the problem.

If you just look at the repository's structure it seems the author went to great lengths to avoid mentioning anything relevant to the domain at hand. That is exactly the opposite of what should happen. At every turn you should be focused on using the exact terminology your business peers use.

• Steve: I believe so looking at the number of stars and forks of that repo. I try to find many repository on simple online banking or atm project which has layered architecture. This is best I could find.

Answer 2

I see this as strict separation between the domain model and the persistence model. By duplicating this model, it becomes possible to fine-tune models for their specific purpose. One represents business rules, other is easy to persist and query. If it was just single model, it would be necessary to make tradeoff-s between the two.

This is specific way to implement DDD. In plain DDD, there is nothing that talks about how the domain entities should be persisted. It is considered a secondary concern. In DDD, you would only think about the domain entities and how those entities are persisted is decided elsewhere.

But in case of this specific implementation, I find there is one thing incorrect. In DDD, the repositories are part of the domain model itself. That means that the repository should work with domain entities, not persistence entities. But that is what is happening here. Transformation from domain to persistence entities happens in services, which is wrong place to do it. It should happen inside the repositories. This way, it becomes implementation detail of a repository. This way it is irrelevant to the user of the repository if the repository is using EF, plain SQL or something different to actually persist the data.

Example of the above is in /src/Frameworks/Transaction/Services/TransactionService.cs in method CreateTransactionAndUpdateSummary (using AutoMapper):

// transform domain entity to persistence entity 
var accountTransactionEntity = _mapper.Map<AccountTransactionEntity>(accountTransaction);
var accountSummaryEntity = _mapper.Map<AccountSummaryEntity>(accountSummary);
// call repository with persistence entities
await _accountTransactionRepository.Create(accountTransactionEntity, accountSummaryEntity);
var currentSummary = await _accountSummaryRepository.Read(accountTransaction.AccountNumber);
// transform persistence entity to domain entity
var result = _mapper.Map<TransactionResult>(accountTransactionEntity);

The above code should be inside the repository itself, not in the service.

• Steve: What do you mean by "Transformation from domain to persistence entities happens in services" and "Transformation should happen inside the repositories."?
• Euphoric: @Steve see edit.
• Euphoric: @Steve Don't be hasty in accepting answers. There might be others with better insights. Accepting an answer might discourage others to provide their answer. I recommend to give a question 24 hours before accepting an answer.
• Thadeu Fernandes: Really liked how this answer clarifies why domain entities and database models should be different, but shouldn't repositories be implemented for aggregates instead of domain entities?
• Euphoric: @ThadeuFernandes Yes, you are correct. But I haven't seen any aggregates in the example code, so I didn't mention them.

Answer 3

Aggregates ARE domain entities - domain entities that contain other entities, thereby modelling one or more conceptual relationships.

• Andy: This does not really address the question.