Previously organized “DDD Stratification” and “Layered Architecture”

Recently see net friend discussion, sort out some have bright spot place

Now layered architecture + clean architecture seems like a panacea

Prior to DDD’s standard hierarchy:

What’s the difference between the traditional layering on the right and the DIP improvement on the left?

If you’re sharp-eyed, you can tell there’s a real difference

Line 1: Application to Infrastructure is reversed

Line 2: This line is gone. This line is common in MVC, where Applicaton and domain are not separated, but it is not recommended in DDD and is generally not used even in loosely layered architectures, except for simple CRUD projects

Line 3: has also been reversed, which is actually similar to the Q part in CQRS

Above comes from the discussion of group friends, is really nothing in the world, if you put your heart into it; I never noticed the difference

This figure comes from the hand of Ali Daniel Yin Hao, “Ali DDD four bullets” has been summarized, DTOAssembler on the application layer, some is not reasonable

In Layered Architecture, thrift’s TService, in order not to duplicate with the controller, requires an Application Service, in which case thrift and the controller can have the same business requests

In other words, there are multiple inputs to the controller, but to the application layer, they are all the same user case. If you put them in the application layer, you should expose more methods than methods for the same use case

The adaptation layer does three things:

  1. Protocol adaptation (such as controller, with @RequestMapping annotation and JSON serialization)
  2. Validation of parameter rules (e.g., cannot be empty, cell phone is numeric and 11 digits, email must have @, etc.)
  3. Transform the input (Assembler) to invoke the lower layer (application layer)

If there are four layers:

  1. Controller (Assembler, Transformation)
  2. appliction
  3. domain
  4. Repository (convertor)

The application layer is the real business entrance, which is a very thick layer:

  1. It is used to coordinate domain operations, which can vary depending on the system architecture, mainly divided into synchronous invocation and step event.
  2. Operations with separation of concerns (such as logging, notifications, and so on)

Application Service Orchestrates services and Domain Service orchestrates domains