Field-driven design: The Way to cope with software core complexity (I)

Field-driven design: The Way to cope with software core complexity (I)

It has been at least 20 years since leading software designers began to regard Domain Modeling and design as a key issue, but surprisingly, there is almost no relevant literature to tell everyone what to do and how to do it. Although Domain Modeling and design are not clearly formal, there is a potential philosophical system in the object field, which is what I call domain-driven design ).

 

Each software program is related to your activities or interests. The main environment in which the user uses the program is called the domain of the software ).

 

The core of software is its ability to solve domain-related problems for users.

 

Creating programs that can handle very complex tasks requires separation of focus, which allows separation of focus on different parts of the design. At the same time, no matter whether the system is separated or not, it is necessary to maintain the complex interaction in the system.

 

Layering means that each layer is responsible for a specific aspect of computer programs. This dedicated division makes all aspects of the design more cohesive and easier to interpret. Of course, it is very important to select layers to isolate the most important aspects of cohesion design. Fortunately, experience and management can help us again. Despite many variants, most successful layered architectures use some of these four conceptual layers.

Used for the interface layer (presentation layer): displays information to users and parses USER commands. External executors may sometimes be other computer systems, not necessarily human beings.

Application Layer: defines the work that can be done by the software and directs domain objects with rich meanings to solve the problem. The tasks in this layer have a profound impact on the business, and it is necessary to interact with the application layer of other systems. This layer must be concise. It does not include processing business rules or knowledge, but only coordinates tasks and commissions for the domain objects that collaborate in the next layer. This level does not reflect the status of the business, but the status of the task progress of the user or program.

Domain Layer (model layer): represents business concepts, information about business conditions, and business rules. Although the technical details for saving the content are completed by the infrastructure layer, the status that reflects the business status is controlled and used in this layer. This layer is the core of business software.

Basic structure layer: provides general technical capabilities for the upper layer: Message sending and domain persistence of applications, and drawing windows for user interfaces. Through the architecture framework, the infrastructure layer can also support interaction between the four layers.

 

Divides a complex program into layers. Designed for each layer, each layer is cohesive and only dependent on its lower layer. The Standard Architecture mode is used to achieve loose association with the upper layer. All Code related to the domain model is centralized at one layer and separated from the code at the user interface layer, application layer, and infrastructure layer. Domain objects can focus on expressing domain models without worrying about their own display, storage, and management of application tasks. In this way, the model is developed rich and clear enough to grasp the essential business knowledge and implement it.

 

Separating the domain layer from the basic structure layer and the user interface makes the design of each layer clearer. The maintenance overhead of isolated layers is much lower, because they often develop at different speeds and respond to different requirements. Separation can also facilitate the deployment of distributed systems. To minimize communication overhead and improve performance, you can flexibly place layers on different servers or clients.

 

A layer is a loose association structure because the design dependency is unidirectional. Upper layers can directly use or manipulate lower-layer elements. This can be accomplished by directly calling lower-layer PR interfaces to maintain references to them or using conventional interaction methods. However, when a lower-layer object needs to communicate with the upper-layer object, we need another mechanism to connect the layers in architecture mode, for example, callback or observer mode.

 

The earliest pattern used to connect the user interface layer, application layer, and domain is MVC.

 

The infrastructure layer usually does not initiate an action at the domain layer.

 

The application layer and the domain layer call services provided by the infrastructure layer.

 

A framework that integrates many basic structures often requires other layers to be implemented in a very specific way, for example, as a subclass of the framework class or using a Constructed Method signature. The best architecture framework allows field developers to concentrate on expressing a model while solving complex technical problems. However, the framework can easily lead to obstacles. Either too many things are assumed, limiting the choice of design in the field; or too many things are implemented, which affects the development speed.

 

Nowadays, the layered architecture is used in most systems, but the hierarchical architecture of each system may be different. Many development styles can be used in different layers for help. However, the domain-driven design requires only one specific layer.

Domain Models are a set of concepts. The domain layer is a manifestation of the model and all its associated design elements. The Design and Implementation of business logic constitute the domain layer. In a model-driven design, the software structure of the Domain Layer reflects the concept of the model.

When the domain logic and other focus of the program are mixed together, it is unrealistic to achieve consistency. The implementation of isolated domains is a prerequisite for domain-driven design.

 

Anti-pattern-smart UI

 

Many software projects adopt and will continue to adopt an immature design method, which I call intelligent UI. However, the intelligent UI has taken on the other side, as if the road is mutually exclusive, and is incompatible with the domain-driven design method.

 

Submit the business logic of all services to the user interface for processing. Divide the entire application into small functional functions and implement them as independent user interfaces. Meanwhile, the business rules are embedded into these interfaces. A relational database is used as the shared storage of data. Use the most automatic UI structure and the visualized programming tools available.

It's just a few minutes away!

 

(Currently popular, including those advocated in this book) truth is that the domain and UI should be separated.

 

Therefore, in the context of domain-driven design, we can regard this intelligent UI as an "anti-pattern", although it is a reasonable pattern in some contexts.

 

There are other solutions between the smart UI and the layered architecture. For example, in the transaction Script Mode proposed by Fowler, it separates the user interface from the application, but does not provide an object model.

 

Unfortunately, in addition to the infrastructure and user interface, there are other factors that undermine your sophisticated domain model. You must consider those domain components that are not fully integrated into the model.