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?

3 Answers 3


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.

  • 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.
    – Steve
    Jan 21, 2020 at 14:06

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.

  • What do you mean by "Transformation from domain to persistence entities happens in services" and "Transformation should happen inside the repositories."?
    – Steve
    Jan 21, 2020 at 12:26
  • 1
    @Steve see edit.
    – Euphoric
    Jan 21, 2020 at 12:29
  • 1
    @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.
    – Euphoric
    Jan 21, 2020 at 12:41
  • 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? Feb 10, 2020 at 11:24
  • @ThadeuFernandes Yes, you are correct. But I haven't seen any aggregates in the example code, so I didn't mention them.
    – Euphoric
    Feb 10, 2020 at 12:52

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

  • 1
    This does not really address the question.
    – Andy
    Jul 23, 2020 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.