- https://medium.com/raa-labs/part-1-domain-driven-design-like-a-pro-f9e78d081f10
- https://medium.com/tacta/a-decade-of-ddd-cqrs-and-event-sourcing-74edc8211039
- https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf
- https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf
- https://thephp.cc/news/2020/04/improve-design-with-cqrs
- https://www.infoq.com/minibooks/domain-driven-design-quickly/
- https://www.youtube.com/watch?v=395r-jzj8_k
- https://www.youtube.com/watch?v=Ru2T4fu3bGQ
A common architectural solution for domain-driven designs contain four conceptual layers:
Responsible for presenting information to the user and interpreting user commands.
This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress.
This layer contains information about the domain. This is the heart of the business software. The state of business objects is held here. Persistence of the business objects and possibly their state is delegated to the infrastructure layer.
Layer This layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects, contains supporting libraries for the user interface layer, etc.