Field-driven design-basic architecture

I. Why should we use Domain Models?
• Helps the Team create a general model that can be understood by both the business department and IT department, and use this model to communicate business requirements, data entities, and process models.
• The model is modular, scalable, and easy to maintain. The design also reflects the business model.
• Improves the reusability and testability of objects in the business field.
2. Layered domain Architecture
Eric Evans's domain-driven design-the way to cope with software core complexity-the layered architecture of the domain is as follows:

• User Interface (presentation layer): displays information to users and explains USER commands.
• Application Layer: This layer coordinates application activities. It does not include any business logic, does not save the state of the business object, but can save the state of the application task process.
• Domain Layer: This layer includes information about the business domain. The status of the Business Object is saved here. The persistence and status of business objects may be delegated to the infrastructure layer.
• Infrastructure layer: for other layers, this layer is a supporting library. It provides information transmission between layers to ensure the persistence of business objects, including a support library for the user interface layer.
3. How to Create a domain model
• Search for concepts
• Draw it as a class in the UML class diagram
• Add associations and attributes
Iv. development steps of Domain Models
• Domain Modeling
• Design
• Development
• Unit test and integration test
• Improve and reconstruct the domain model based on design and development
• Repeat the above steps using the updated Domain Model
V. Actual Project Design
1. hierarchy:

2. Interaction between layers
A. Submit Form data to action on the page. action creates a DTO object and sets the corresponding attribute value as form data.
B. Action: Pass the DTO object to the facade.
C. Apply the servicetemplate transaction template in facade to join the transaction management. In servicetemplate, call factory or reposistory based on the specific business, and create or load the domainmodel object respectively.
D. Pass the domainmodel object to the service through facade.
E. The service executes the specific business logic (call the corresponding business method of the domainmodel object)
F. The service calls reposistory to perform persistent operations on the domainmodel object whose status has changed (call the corresponding Dao)
Note:
If you need to query the attribute values in the domainmodel object in facade or service, call the getdatainfo () method of the domainmodel object to obtain the datainfo object and query the required data through the datainfo object, includes the business data that the service returns to the fa c Ade service processing result.
3. domainmodel Design
The domainmodel is designed based on the anemia model. In Robbin's summary of recent discussions on domain objects and related topics, the segmentation principles for the anemia model field are written as follows: the principle proposed by Rod Johnson is "case by case ", highly reusable, which is closely related to the domain object status in item, with low reusability, and not closely related to the domain object status in itemmanager.
The principle I proposed is to check whether the business method explicitly depends on persistence.

In this project, the business logic methods in the DomainModel do not have any dependency on the DAO interface. To perform persistence operations on the DomainModel, the Service calls the Reposistory store () method for processing, all the persistent operations on DomainModel have been encapsulated in Reposistory. DomainModel only provides the business processing method for changing its own status.
4. DomainModel access principles
A. Each attribute of the operation model must be taken from the root of the domain model.
For example, the structure of a domain model is as follows: Java code

1. Public class PersonDomainModel {
2. Person person;
3. Bank bank;
5. Public void modifyPerson (String name, String age ){
6. This. person. setName (name );
7. This. person. setAge (age );
8. }
9. }

public class PersonDomainModel {    Person person;    Bank   bank;    public void modifyPerson(String name, String age) {        this.person.setName(name);        this.person.setAge(age);    }}

The person attribute that operates the domain model can only be performed using the modifyPerson () method, but cannot directly call the setter method of the person object.
B. The integrity of the domain model must be maintained. When a model is initially constructed by the Factory, it must be fully initialized, instead of just constructing a part, and then gradually improved in the next process.
5. Duties of Factory and Reposistory
Factory is only responsible for creating domain model objects (from scratch );
Reposistory encapsulates persistence and operates on existing domain model objects (read data from the database or repersists to the database)
6. Project to be optimized
When the Service calls the store () method of Reposistory for persistence operations, if a Service only modifies some of the DomainModel attributes, when it is persisted to the database, all the attributes of DomainModel will be updated once. Such database operations are unnecessary. You only need to perform persistent operations on the modified attributes in DomianModel. You can consider providing a list on the DomainModel that is similar to saving all the attributes modified. When the Reposistory is persistent, you only need to modify the attributes in the list.

References:
1. Eric Evans "domain-driven design-the way to cope with software core complexity"
2. Robbin summary of recent discussions on domain object and related http://www.javaeye.com/topic/11712