TransWikia.com

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

Software Engineering Asked on November 26, 2021

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

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

Answered by Web Houlgrave on November 26, 2021

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.

Answered by Robert Bräutigam on November 26, 2021

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.

Answered by Euphoric on November 26, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP