Architectural issue on Domain models

[Emre Savcı]

I've seen that your domain models are depend on infrastructure layer (which is context/orm in your project structure). It is an anti-pattern in domain driven design, domain layer must not be depend on infrastructure/application layers.

[eonezhang]

@mstrYoda do you have more best practice to implement DDD

[Emre Savcı]

DDD is an approach to handle projects which have complex business requirements. It could implemented by following patterns like hexagonal architecture, clean architecture or onion architecture.

More generally, while developing applications we want to make it modular, independent layers. Especially the domain layer must not be depend some implementation details like how we obtain an entity.

Here is an explanation of hexagonal architecture: https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/

If you take a look at the hexagonal/onion architecture, domain layer is in the center and not depends any other layers. Infrastructure layer is more outer layer and it depends domain layer.

Some implementations:

https://github.com/ivanpaulovich/hexagonal-architecture-acerola
https://github.com/ivanpaulovich/clean-architecture-manga

[Junichiro Kazama]

Thank you for your feedback.

This is simply a reference to Evans's Domain-Driven Design, and I'm not choosing the recent, redundant approach. Certainly, I think that originally Evans's book allowed Domain to depend on Infrastructure.

I would like to realize a domain model with reduced code so that it can be used in practice. It is good to create many classes for a clean architecture, but I think it is important to compromise with moderate abstraction to make domain modeling realistic.

This sample is just one approach and not an answer.