Reprinted from https://my.oschina.net/hosee/blog/919426
In the decomposition of complex software systems, stratification is one of our most commonly used means. However, in the field-driven design, the division level and there are certain packages look different from our structure, this paper discusses the differences in DDD layered architecture and the significance of each layer, as well as with the traditional three-tier architecture.
- Why hierarchical
software design layered design can be seen everywhere, but stratification can bring any good? Or, why should we consider a hierarchical structure?
Because of the complexity of the real world, it can provide a relatively high-level hierarchical perspective to break down and simplify our problem, in addition to tiered benefits can also be testable aspects, maintainability, flexibility, scalability and so on.
Reduce complexity, separation of concerns, structural clarity;
reduce the coupling, isolation levels, reduce dependence (lower layer an upper layer without concern for the specific implementation), it facilitates the division, testing and maintenance (maintainability);
flexibility, a flexible layer is replaced implementation;
increase scalability, easy implementation of distributed deployment;
looks very simple, it seems that the system is divided into a certain number of layers, and stacking them organized. However, when the implementation of specific practices, how to divide, meaning layers exist, and how to choose the appropriate dependency but not so easy to imagine, specific decomposition overlap part of the boundary, the focus under different scenarios, the internal level and the level of graininess problem we need to consider.
- What is layered architecture
2.1 layered history
of the most well-known should be the classic three-tier architecture: presentation layer, business logic, data access layer.
Martin Fowler in "Enterprise Application Architecture" is also similar to the three are expanded: the presentation layer, field layer, the data source layer.
There are a variety of other layered architecture here is not described.
Faced with such a multi-layered architecture, we can not help but think, based on what they stratification is? Ability to abstract some of the similarities and differences? What should the appropriate intermediate layer at what time to join? In practice, what kind of architecture should we take it?
2.2 hierarchical nature of
stratification is in fact the series of the same or similar objects are classified in the same layer, and then determine the relationship between the upper and lower levels in accordance with the dependencies between them. It can be seen that the core hierarchical classification and association.
In general, we can change the system into a larger part of the business and the relative stability of the technical part; for business, the show can be divided into portions (foreground) and internal processing logic (background) two parts; display can be divided into data / page portion and the interface portion. This constant segmentation and abstraction, we can iterate a more fine-grained classification / hierarchy, as follows:
Business: need to focus on, our aim is also isolated specific areas of the business logic:
External Display (presentation layer / Interface Layer): data page (Web), a remote interface (interface / api)
internal logic: the application logic (Application Layer / service layer), specific business logic (domain layer)
art: relatively stable, specific business-related (infrastructure layer)
Data Access (Data Access Layer)
logs, security, exceptions, cache, etc.
Of course, the classification is not unique, we may have different classification criteria based on different perspectives. Such as the data access layer can also be classified into the business-related / internal logic processing section, since the operation may involve some specific business table.
In addition, according to the complexity of the problem areas and solutions, we can have different levels. For example, in less complex business, we can put the application and domain layers merged into one.
- DDD classic layered architecture
above, we also mentioned some basic level and classification criteria in the analysis of hierarchical nature, but that is only a very coarse-grained division.
In the actual decision-making, we need to know the role of each layer, the significance and the corresponding scene; and when to implement the code level, we also need to know the specific content of the layers contain layers of some common specific strategies / mode level interaction / between dependencies.
First we look at a layered architecture Evans mentioned in the "Domain Driven Design" in.
Q: Why should this be divided into four?
The main purpose is to simplify layered complexity, the system should be the most complex part of our business logic. When the system is more complex interaction or workflow, we will consider this extract from the business logic as part of the application layer. And the code within each field into the field of the layer, so that the hierarchical structure clearer.
3.1 User interface layer / presentation layer
user interface layer is responsible for displaying information to the user and interpret user commands. Here the user can refer to another computer system, not necessarily the person using the user interface.
The layer comprising the other applications (such as web services, RMI interface or batch, and the front end web application) to interact with the communication interface facilities.
It is responsible for the interpretation of the input parameters, validation and conversion. In addition, it is also responsible for the sequence of output parameters, such as serialized by the end of the HTTP protocol to the web browser or web services client transfer HTML or XML, or Java remote clients and remote DTO class appearance of the interface.
As can be seen, the primary responsibility layer with external users (including web services, other systems) interaction, such as accepting user feedback, information showing necessary data. The main part contains the web and remote services section and so on.
common web portion generally comprises Servlet, Controller and other components, and the remote interface unit is mainly composed Facade, DTO Assembler and the like.
The Facade: Remote appearance, the appearance of a coarse-grained, free of any domain logic
the DTO: Data Transfer Object
Assembler: Object assembler, is responsible for the data transfer object with the object field conversion and not to expose
Q: Why calibration parameters in the user interface Floor? Check and verify the user interface layer, the domain layer What is the difference?
Check should depend on the contents of the check, the check is generally recommended as soon as possible, but here is mainly carried out some simple checksum does not involve business rules. Specific business rule check on field layer.
Q: Why do I need DTO? DTO and VO is the same thing?
Object-relational areas are more complex and difficult to serialization, and users often do not need the whole model, most of the time needed just one part of the content, DTO can effectively reduce the cost of network calls. Further, the internal logic of the domain model need not be exposed to the outside.
DTO typically used for remote service, if it is used internally, it can generally be used directly domain objects.
VO has a front end status information, such as success or failure and the like.
Q: Why do I need Assembler?
The main purpose is decoupled, it is responsible for conversion between the data transfer object and the field object. BeanUtils can do the corresponding function (dozer relatively better), but Assembler clearer, safe and controllable, the disadvantage is that the amount of code by hand slightly.
3.2 Application Layer
Application layer defines the software to complete the task, and direct expression of the concept of the object field to solve the problem. This layer is responsible for the work of great significance to the business, it is also necessary channels to interact with other systems in the application layer.
The application layer to be as simple as possible. It does not contain business rules or knowledge of tasks, just to the next level domain object to assist the task entrusted to work. It does not reflect the state of the business situation, but it may have reflected the state of progress of a task or the user of the program.
The application layer is responsible for the organization of the entire application process is designed for the use case. This layer is very suitable for transaction processing, logging and security. With respect to the domain layer, an application layer should be a thin layer. It's just an object field of the coordination layer performs the actual work.
In summary, the application layer is the primary means of user case and the user story expression, mainly for coordination with other application domain model components (not business logic).
The main component is the application layer Service, because the main duty is to coordinate the various components work, so often interact with multiple components, such as other Service, domain objects, Repostitory and so on.
It is a relatively common practice: an application layer generally accepted parameters from the user interface layer, and then obtained by polymerization exemplary Repostitory, and then performs a corresponding operation command (very thin layer).
Q: Why should the application layer?
When more complex operations, we can split the field of the application layer and from the business logic layer.
If the advance for a particular application logic, reduces the reusability between applications in the field of object.
Further, if in the future the workflow tools need to add such logic to implement the application, if it was previously mixed together is not split.
3.3 domain layer / layer model
field layer is mainly responsible for expressing business concepts, service status information and business rules.
Domain layer is the core layer of the system, almost all of the business logic will be implemented at this layer.
Domain model layer mainly includes the following content:
Object has a unique identity: Entity (Entities)
value of the object (Value Objects): no need to uniquely identify
areas of service (Domain Services): some behaviors can not be classified into solid objects or value objects, the nature of some operations, not of things
polymerization / aggregate root (Aggregates & Aggregate roots): polymerization refers to a group having a set of related objects cohesive relationship, and each has a root and a polymerization boundary
plant (factories): create complex objects, hiding the details of creating
storage (Repository): Find and methods provide a persistent object
on the specific meaning of each element, duties and related errors, refer to the field of analytical modeling of the core concepts.
for these specific objects, define some standard collar Annotation to regulate.
3.4 infrastructure layer
passes the message to the application layer, providing persistence mechanism for domain layer, draw the screen as the user interface layer components: infrastructure layer on top of each layer to provide a common technical competence.
Infrastructure layer in different ways to support all three layers, layer facilitate communications between.
Infrastructure includes all independent of the existence of our application: external libraries, database engines, application servers, back-end messaging and so on.
As the infrastructure layer, Infrastructure as Interfaces, Application Layer and Domain to provide support. All associated with the particular platform, will provide the framework for achieving Infrastructure, avoiding in particular three Domain doped into these layers to achieve such "contaminated" domain model. Infrastructure is the most common type of facility is the object persistence implementation.
Q: What role Repository? And the relationship of DAO
before Repository have had misunderstandings (in our system there is a repository layer is located between the dao and service).
DAO is primarily from the perspective of the database table to look at the problem, and provide CRUD operations (only a package of database table), a process for the style data (transaction script);
and the Repository (repository) and Data Mapper ( the data mapper) more object-oriented, model commonly used in the art.
Because access to the exposed layer of encapsulation may damage the object data, object relationships and data consistency is difficult to maintain, so should be avoided in the domain model DAO mode, the polymerization is recommended to manage business logic itself.
- Shape model of
a different architecture, different layers, different application scenarios has a different modeling needs, so the expression of the model the same concept may have different forms, such as:
Congestive Model: Model art architecture includes logical domain model field and field attributes.
Hemorrhagic models: the traditional three-tier system only get / set methods, POJO objects no business logic.
Anemia Model: hyperemia model is similar to, but not including persistence associated logic.
PO (Persistant Object): persistent object, i.e. taken out of DAO JDBC objects. Traditional three-tier architecture, PO i.e. POJO component objects exists between DAO and Service.
DO (Domain Object): art object domain model architecture, PO after taken out from the database, the concept of a "reconstruction", i.e. to restore the data entity, this entity is the reduced DO, is present between the Service and DAO .
DTO (Data Transfer Object): data transfer object. The traditional three-tier architecture, the object exists in between the Service and the Controller. PO conversion to DTO or may be implemented in a Service Controller.
VO (View Object): view object. Controller DTO when returning to the view, the state information may also need to include, for example, the successful operation / failure status code, and the like prompt text. Then you need Wrap an outside DTO, i.e. View Object. This object is present between the Controller and the Web, assembled by the Controller
