Extending the four-tier model of the architecture proposed by Eric Evans

Article summary

Eric Evans, the creator of Domain Driven Design, proposed the following four-layer model in program development. ** ・ Control layer ・ ・ ・ Responsible for connecting to the app at RestApi. ** ** ** ・ Use case layer ・ ・ ・ Responsible for the business logic of the application. Domain layer methods are aggregated here. ** ** ** ・ Domain layer: A layer that describes common processing. Call in the use case layer. ** ** ** ・ Infrastructure layer ・ ・ ・ Responsible for technical logic that depends on external libraries such as mail and FTP connection. Called from a layer other than the infrastructure layer. ** **

Domain Driven Design is a concept advocated in early 2000. Since then, Domain Driven Design has evolved, and new design methods that combine domain-layer methods such as CQRS and event sourcing have emerged. The expansion of the domain layer has saturated the four-layer model of the architecture proposed by Eric Evans, complicating the design. This article aims to add layer layers to the ** architecture four-layer model ** to make Domain Driven Design more sophisticated and simple.

Add a mission layer that aggregates domain layer methods to the 4-layer model

In Feature Driven Development, domain layer methods are called by function (feather) units, and planning, design, coding, unit testing, and release are performed. https://www.lucidchart.com/blog/why-use-feature-driven-development

By creating a function (feather) class that aggregates the methods of the domain layer, it acts as an intermediary between the use case and the layer and the domain layer. Following the model of Feature Driven Development, we propose to add a ** mission layer ** that aggregates domain layer methods to the ** 4-layer model **. The following is a comparison diagram of the ** 4-layer model ** and the ** 5-layer model ** with the ** mission layer ** added.

Side effects caused by adding a mission layer to the 4-layer model

** The domain layer is isolated from the use case layer ... Since the domain layer is isolated from the use case layer, the influence of the change of the use case layer does not spread to the domain layer. ** **

** A space to describe the logic of CQRS or event sourcing can be provided ... CQRS or event sourcing can be described in the mission layer, so the logic outlook is improved **

Direction of future development of the 5-layer model

The following course is predicted as the direction of development of the ** 5-layer model **.

** ・ Apply the concept of DCI architecture to the mission layer so that it can meet a wide range of demands from the use case layer ** https://qiita.com/aLtrh3IpQEnXKN7/items/355ad12f82ac424abea3

** ・ The use case layer is layered for each request level, and the reason for calling the mission layer method is clarified ** https://qiita.com/aLtrh3IpQEnXKN7/items/853ecb3cd109dd016476