Domain Driven and Modular Design! part 2

article

Domain Driven and Modular Design! part 2

Clean architecture

Mostly about how to organize your file structures to make it easier for all developers to be part of the development team, by following clean architecture, all base code seems unified and easy to understand.

Clean architecture is also known as clean code and Onion architecture because it’s layered break down and contains

· Core layer (Abstractions, entities, and rules)

· Application layer (Employer of infrastructure to implement core rules)

· Infrastructure layer (All stuff about persistence and external connections)

· Interface layer (API or Web)

Clean architecture is a lower-level concept compared to https://www.linkedin.com/pulse/domain-driven-modular-design-part-1-reza-bashiri/?trackingId=3jJBdAPbRD%2B06ARhNIIHpw%3D%3D concepts and tech team will be in charge to following those.

All together

Mixing design architecture:

1. Each module represents a separate bounded context

2. Technical team and domain experts will have a common language in the solution

3. API gateway and message busses don’t need any more

4. Any new requirements can easily be embedded into the system without any effect on current modules.

Now let’s put it all together and determine the position of Domain Driven Design, Modular system, and Clean code:

1. DDD: Is looking to problem and solution by domain experts and technical team, aim to introduce a common language between them and break down the system to meaningful subdomains and extract domain model

2. Modularity: Breaking down the system to independent libraries or executables to ease development and maintenance.

3. Clean architecture: Breaking down each module or whole monolith project into multiple layers to follow SOLID principles