Domain Driven design and practice

Domain Driven design and practice (forwarding) Author: Chi Jianqiang Source: InfoQ Published: 2013-12-01 13:03 read: 12,261 recommendations: 35 original link [favorites]Abstract: This paper introduces the basic concepts, elements and characteristics of domain-driven design, compares the features of transactional scripts and domain models, and finally introduces the field-driven design practice in software development. Introduction

The object-oriented design of software system has a long history, the the 1970s Smalltalk can be said to be the classic object-oriented language, until today we still regard this language as the basis of object-oriented language. With the development of programming language and technology, various language features are emerging, object-oriented is a basic feature of most languages, such as C + +, Java, C # static language, such as Ruby, Python Dynamic language is object-oriented language.

But object-oriented languages are not silver bullets, and if developers think that the extent to which they write in object-oriented languages is inherently object-oriented, it is a big mistake. In actual development, a large number of business logic piled up in a huge class of examples are not uncommon, code reusability and extensibility can not be guaranteed. In order to solve this problem, domain-driven design puts forward the concept of clear hierarchical architecture and domain object, and makes object-oriented analysis and design enter a new stage, which plays a great role in the development of enterprise software.

This paper mainly introduces the basic concepts, elements and characteristics of domain driven design, compares the features of transactional script and domain model, and finally introduces the field-driven design practice in the process of software development.

What is domain driven design (DDD)

Eric Evans, a leading modeling expert in 2004, published his most influential book: Domain-driven design:tackling Complexity in the heart of software ( Domain-driven design: The core complexity of software, the concept of domain-driven design (DDD) is presented in the book.

Domain driven design is in fact an extension and extension of the Ooad, DDD is based on object-oriented analysis and design technology, the technical architecture of the hierarchical planning, at the same time, each class is divided into policy and type.

Domain model is the core of domain-driven. Using DDD's design philosophy, business logic is no longer concentrated on several large classes, but rather consists of a large number of relatively small domain objects (classes) that have their own state and behavior, each of which is a relatively complete independent body and is mapped to a business object in the real world. The domain model is made up of so many fine-grained classes. The domain-driven design ensures the maintainability, extensibility and reusability of the system, and has inherent advantages in dealing with complex business logic.

Features of domain-driven design

The domain-driven core application scenario is the solution to complex business design issues, and its characteristics are closely related to this core theme:

1. Hierarchical architecture and Responsibility Division: domain-driven design well follow the principle of separation of concerns, put forward a mature, clear hierarchical structure. At the same time, the domain objects have a clear strategy and responsibility division, so that the domain objects and real-world business to form a good mapping relationship, for the domain experts and developers to build a bridge of communication.
2. Reuse: In domain-driven design, the domain object is the core, each domain object is a relatively complete and cohesive business object description, so it can form a direct reuse. At the same time, the design process is based on domain objects rather than database-based schemas, so the entire design can be reused.
3. Usage scenarios: For software systems with complex business logic, the maintainability and extensibility requirements of the software are high. Do not use simple additions and deletions to check the business.

What if DDD is not used?

Faced with complex business scenarios and requirements, if the domain model is not established and implemented, it leads to a rich service layer and a domain model of anemia in the application architecture, in which the service layer begins to accumulate more and more business logic, and the domain object becomes a data carrier with only getter and setter methods. This approach also leads to the spread of domain-specific business logic and rules across multiple service classes, and in some cases, repetitive logic. We've seen more than 5,000 lines of service classes, hundreds of methods, and the code is basically unreadable.

In most cases, the domain model of anemia is not cost-effective. They do not give companies a competitive advantage over other companies because it takes too long to develop and deploy into a production environment to change the business requirements in this architecture.

Hierarchical architecture and constituent elements of domain-driven design

Here's a brief introduction to the layered architecture and elements of domain-driven design, which is described in a very detailed way in Eric Evans's book, and it's best to read the original book.

The following diagram is a well-known hierarchical architecture diagram in the book, as follows:

The entire architecture is divided into four tiers, the core of which is the domain layer (domain), and all business logic should be implemented at the domain level, as described below:

User interface/Presentation layer	Responsible for presenting information to users and interpreting user commands.
Application Layer	A thin layer that is used to coordinate the activities of the application. It does not contain business logic. It does not preserve the state of the business object, but it retains the progress status of the application task.
Domain Layer	This layer contains information about the domain. This is where the business software is at the core. Here the state of the business objects is preserved, and the persistence of the business objects and their states is delegated to the infrastructure layer.
Infrastructure Layer	This layer exists as a support library for other layers. It provides inter-tier communication, which enables the persistence of business objects, including support libraries for the user interface layer.

In addition to a hierarchical description of the system architecture, the domain-driven design also has a clear responsibility and strategy for objects (object):

1. Entity (entities): has a unique ID, can be persisted, with business logic, corresponding to the real-world business objects.
2. Value objects: Does not have a unique ID, is described by an object's properties, typically an in-memory temporary object that can be used to pass parameters or to supplement the description of an entity.
3. Factory (factories): mainly used to create entities, the current architectural practice of the IOC container is generally used to achieve the function of the factory.
4. Warehouse (repositories): Used to manage the collection of entities, encapsulating the persistence framework.
5. Services: Provides an operational interface for the superstructure, which is responsible for dispatching and encapsulating domain objects, while providing various forms of service to the outside world.

Of course, the concept of aggregation and aggregation root (Aggregate root) is also presented in DDD, but in practice we find that the convergence root has a tendency to complicate problems, and the concept of traditional aggregation and composition to describe the relationship between domain objects is easier to understand, so there is no introduction to this concept.

Transactional scripts and Domain models

Martin Fowler The Nineth domain logical model (domain logic) in the Enterprise Application Architecture model (Patterns of enterprise Application Architecture) in 2004 Patterns) is dedicated to transactional scripting (Transaction script) and domain model, and understanding these two patterns is very helpful in designing and building enterprise applications, so it's important to introduce them.

Transaction script:

The core of a transactional script is a process that organizes business logic through calls to the process, each processing a single request from the presentation layer. Most business applications can be viewed as a series of transactions, which, to a certain extent, deal with business through transactional scripting, just like executing a bunch of SQL statements to implement database information processing. A transactional script organizes the business logic into a single process, invoking the database directly in the process, and the business logic is processed at the service level.

The transaction script pattern can be simply represented in UML diagrams like this:

By handling the action request of the UI layer by the action layer, the data in the request is assembled and passed to the BUSINESSSERVICE,BS layer for simple logical processing, and the data access object is called for data persistence, in which VO acts as the object of transmission, and is generally the pojo of anemia, Only getter and setter methods are available, with no state or behavior.

Transactional scripting patterns are characterized by simple, easy-to-understand, process-oriented design. For a small number of logical business applications, the transactional scripting pattern is simple, natural, well-performing, easy to understand, and the processing of one transaction does not affect other transactions. However, the shortcomings are also obvious, for complex business logic processing, difficult to maintain a good design, redundant code between transactions is increasing, through the copy and paste method for reuse. Maintainability and scalability are poor.

Domain Model:

Domain model is more obvious, belonging to object-oriented design, domain model has its own attribute behavior state, and the real-world business object mapping. Various types have clear responsibility division, domain object elements through aggregation and reference and other relationships to solve real business applications and rules. Reusable, maintainable, easy to expand, and can be designed with the right design model in place. The disadvantage is relatively complex, requiring designers to have good abstract ability.

The domain model corresponds to the domain layer that is divided in the domain-driven design, which is not discussed in detail here.

In the actual design, we need to choose the corresponding design pattern according to the specific requirement. The core business system with complex business logic is suitable for the use of domain model, and the simple information management system can consider adopting transaction script mode.

Field-driven design practices

Here's a look at our practice and expansion of DDD in building an enterprise application development platform.

In recent years, I have been engaged in enterprise-level application development platform related work, Gap platform is one of our software products, used to solve the enterprise-level software development process of reuse, rapid development and process specifications and so on. Design such a platform, from the bottom of the framework should be able to support the complex business logic of the system construction, so we in the large architecture design ideas to adopt the concept of domain-driven design, and based on the actual use of technology and to achieve the function of the four-tier DDD architecture has been refined and implemented:

The entire platform incorporates Java EE Technology and its associated open source framework. The core business logic of the system is handled by the domain layer, where the business Service (Businessservice) handles a relatively cohesive business logic unit while providing local or remote services internally and externally.

Here is a brief description of each layer:

1. View: The exhibition layer, because the gap platform mainly for B/s architecture, the presentation layer consists mainly of web resource files, including Jsp,js and a large number of interface controls, while also using the Ajax and flex RIA Technology, responsible for the user to display rich interface information, and execute the user's commands.
2. Control: is responsible for the presentation layer request forwarding, scheduling and basic verification, while automatically intercepting the background returned runtime exception information, if the control layer needs to interact with a third-party system, you can make a remote request through action.
3. Domain: Domain layer, is the most abundant layer of the system, is mainly responsible for processing the entire system business logic. This layer includes business services and domain objects, and is responsible for the transaction management of the system. Where business services can provide local invocation and the ability to share remote services.
4. Persistence: persistence layer, primarily responsible for data persistence, supports O/R mapping and JDBC. Access to data sources is provided in several ways.

In addition, we have introduced the spring IOC container, the control layer, the domain layer and the persistence layer elements of the system have the unified management of the IOC container, realize the complete interface separation and decoupling. The log service can also be referenced in both the control, domain, and persistence layers.

We have a slightly different definition of the domain-driven element and the original name and meaning.

The original service, which we define as business services (Businessservice), is the core design idea of the gap platform, and a business service can consist of one or more domain models and data Access Objects (DAO), To implement a complete business logic unit. Business services are primarily responsible for transaction processing and maintaining relationships between objects in various domains, while providing local and remote services for upper-level access, including Web Service,rmi.

Domain objects consist of entities (entity) and Value objects (VO), entity classes have their own properties and behaviors, state, can aggregate VO, entity classes can have aggregation associations, etc., can be persisted by the data Access object (DAO).

Persistence is implemented by a data Access object (DAO) that does not handle business logic and is primarily responsible for the persistence of entity classes. Provides multiple persistence modes (O/R mapping and JDBC).

So how do you go about implementing domain-driven design? We have summarized the following four steps:

1. Determine business services: Based on business requirements and functional modules, identify business units, each business service is an in-service unit that covers related domain objects.
2. Define domain objects (Entity, VO): Define domain objects based on business logic of business units, and describe domain objects through UML methods and design patterns.
3. Define attribute and association relationships for domain objects: Determine the various attributes of the domain object and the association between the various domain objects.
4. Add behavior for domain objects: Add behavior to domain objects based on business requirements (System use cases and interface prototypes, etc.) and define which methods are referenced by the business service.

Case Online Bookstore

In order to understand the domain-driven design better, we have realized a simple online bookstore system based on the above design method.

The online bookstore system is an example of an application system built using the DDD design idea. Through the online bookstore system, you can quickly understand the domain-driven design. This system realizes the common functions of the online bookstore: including browsing books, selecting books, submitting orders, viewing orders, automatic discounts, processing orders, canceling orders, etc. Users who are not logged in can browse and select books; the logged-in user can submit and view their own related orders, and the administrator can process the orders.

Through the business abstraction, even such a simple business scenario contains a lot of domain objects, such as orders, accounts, books, shopping carts, shopping items, discounts, etc., through analysis and design, we can get such a design (for viewing convenience, the class in the diagram hides the attribute information):

Bookstoreaction is responsible for processing the presentation layer's request and forwarding the request to the business service Ibookstorebs, which is responsible for the domain objects displayed in the scheduler and handles all the business of the scenario.

The correspondence between the domain object and the real business is:

• Account accounts
• Order Orders
• Book Books
• Cart Shopping Cart
• Item Order Item
• Discount Discount

Unlike the programmatic pattern of transactional scripting, domain-driven design does not place business logic in BS (Businessservice), but rather is handled by domain objects with attributes, behaviors, and states. For example, the order class, if it is an anemic pojo, has only the properties corresponding to the data table field and the getter and setter methods, and in the domain-driven design, it is a relatively independent domain object capable of handling its own associated business. In this system, we describe the order as follows:

The order implementation class is Gap.template.bookstore.model.Order, in addition to the basic properties such as contact, mailing address, and other areas related to the following activities:

1. Init (...), the method is called at checkout, and the order is initialized for the user to modify according to the current user and items in the shopping cart.
2. Submit (...), the method that is called when the order is submitted, and the order is saved.
3. Cancel the order, set the status of the order and the related item to canceled, and then delegate the DAO to persist.
4. Dispose (...), processes the order, first updates the status of the order item, and then delegates the DAO to persist the order data.
5. ReSubmit, Setitemsstatus ...

Through the above description, we can see that the order class basically covers the real world orders the business of all the behavior and state, is relatively cohesive, such characteristics make its reusability greatly increased, even if the future development of new modules, involving order business, you can directly re-use order class. At the same time in the post-maintenance, if I want to know the order of the business, directly read the order code is possible.

From there, we can clearly see the relationship between the objects in each domain. Both order and cart are aggregated with item, corresponding to the 1...n,item aggregation book, corresponding to the relationship 1 ... 1. Order separately with the discount, the account of the association and call, and so on, the whole online bookstore scene is described.

Also, don't forget BS, besides the role of infrastructure (transaction management and service sharing), it is also responsible for scheduling and maintaining relationships between domain objects. Because there will always be some business logic, neither belongs to this domain object, also does not belong to that, that part of the business by whom to deal with? To be handled by BS. For example, in the case of an administrator processing orders, the first need to obtain an account based on the order information, based on the account information to determine the discount rate, while checking the balance, if the verification pass, will call the order object's Dispose method to process the order, this scenario will involve order, accounts, Discount and other objects, such business logic, should be implemented by BS.

Ibookstoredao is a data access object that can be called by BS to persist an object or to be referenced by a domain object to persist itself.

Through the above description, we can see that the entire design and implementation is elegant and clear. Business logic is not stacked in BS, but is dispersed in BS and various domain objects, and services and objects are closely related to the real-world business, both for domain experts, developers, and post-maintenance personnel to get what they need in this way.

Summarize

We use the domain-driven design relatively early, as far as my personal testing and practice, DDD is very important to build enterprise application development platform and large-scale core business system, regardless of product stability, scalability, maintainability, life cycle and other aspects have a significant improvement.

However, because of such reasons (complexity, duration, developer capacity constraints, etc.), many people will unconsciously resist the use of DDD, sometimes a software project rewrite two times, the second time still do not do a good design. In fact, using the DDD design approach, our design phase has become very lightweight and agile, as long as the developer can draw the relationship between the domain model and describe the description, and with the requirements of the people to agree with, then the things done is basically reliable.

In the field of technology, only active attempts and promotion, the effect is the most obvious. Many people ask me, how to start learning and practice xxx, in fact very simple, now start!

Domain Driven design and practice