At first, you must remember, a simple blog system often does not need to use a DDD workshop (like Event Storming) to design and apply a complex architecture. However, when you are skilled, you will find DDD thinking is very usefully for your daily thought. Also, your modeling speed will be more and more fast. So you can quickly complete all the design process in your brain.

These examples aim to demonstrate a DDD architecture with different tech stacks, which can work in the real project and let you understand and reference quickly.

When designing these samples, I refer to the following architecture patterns:

• Hexagonal Architecture
• Onion Architecture
• Clean Architecture
• Microservice

And I designed them with these principles (you can call it CUPET):

• Easy to Code
• Easy to Understand
• Easy to Protect
• Easy to Extend
• Easy to Test

Work in progress...

Work in progress...

Work in progress...

I don't write the test for the specific implementation of repositories, and the instead is inject the repository implementation to services, and write the integration tests for the services.

Because when we used the domain models and services to replace anemic models like POJO or POCO, it makes creating input data for repositories in the tests are very difficult. The more important is only focus on the implementation of repositories is make little sense; they must work correctly in the business context (services).

The test doubles are handy when writing unit tests for services. This way can make the service's tests very easy because we want to focus on the business logic in service, not the implementation of domain models and repositories.

Work in progress...