Domain-driven design-objects in Software

The object about Domain-driven design in the software

Domain-driven design is a way of thinking that aims to deal with software projects with complex problems. In the traditional waterfall software development model, it goes through the stage of requirement analysis, design, development, testing, delivery, etc, however, the problem is that the requirement is not smooth from the business side to the development team. Although complex and detailed requirements documents are organized at the demand stage and detailed design documents are generated at the design stage, developers are rarely involved in problem domain analysis and modeling, their understanding of design documents is often one-sided. Sometimes they may even overturn the design document's model to create some temporary solutions, and there are often high-performance reasons. Many design documents have been shelved since they were written. One of my colleagues, L, said that our document modification date is always just the creation date, because the design document update is far behindCodeSometimes it doesn't mean how big a logical change is, But updating design documents is sometimes more costly than updating code! This phenomenon is common in my projects, and I am increasingly aware of the danger of disjointed design and development.

Developers also have some problems. It is easy for people to concentrate their experiences and skills on technical details. The technical aspects of software networks, databases, and other technical aspects are the favorite content of technical discussion. This also has a lot to do with the environment,CommunityThe Forum is filled with arguments about which editor and language to choose. I have seen many people take pride in being proficient in a framework and want to solve all the problems with the Framework. It took me three weeks to encapsulate the Lua engine, which can seamlessly call the Lua code in C ++ and easily register the C ++ class to Lua, the C ++ template is used to implement the functions of tolua ++ and luabind. But when all this was done, while I was confident in the delivery, my colleague F arranged for me to use Lua to implement the task system. I thought about it, thought about it, and thought about it, I suddenly found out that I had no clue, because I didn't know the logic of the task system, even though Lua's performance is so good, how small, and how concise the syntax is, but without understanding the task system, can I guarantee the development of highly capable services? Even though the implementation of its basic functions is no small challenge, it also supports additional functions such as dynamic addition, modification, and deletion of task definitions by planners.

I gradually realized that the main complexity of many software is not technically, but in the field, user activity or business. If the responsibility of the problem domain is not resolved, the best technology (Lua? Lamada? Async? Multi_thread ?) They are all floating clouds. Each of us has limited energy. Therefore, if we spend too much time learning IDE, then the time spent on learning models and modeling will inevitably decrease.In terms of cognitive overload and cognitive load theory, cognitive resources are required for all cognitive activities in the Process of problem solving and learning. If the total amount of resources required for all activities exceeds the total amount of resources owned by the individual, this will lead to insufficient resource allocation, thus affecting the efficiency of individual learning or problem solving. This situation is called cognitive overload!

I have been paying attention to domain-driven recently.
The design community has benefited a lot. I have new thoughts on software and object technology. These ideas are not mature yet, but I still want to record them in words.

About Association

The most basic relationship between objects is association. In reality, objects are often many-to-many associations, but it is difficult to maintain and understand many-to-many relationships at the code level. If the relationship between object A and object B is one-to-one, it means that object A contains a reference to object B, and object B also contains a reference to object A. If object a corresponds to multiple B objects, then a will contain a set of B objects (vector? Set? Map? Hash_map ?), Object A will also include some methods for Traversing B, searching, and adding. The guiding principle for winning relationships among multiple teams is to add constraints to make them one-to-one relationships as much as possible. For example, the company-employee relationship may be many-to-many relationship, but because someone can only work in one company in a certain period of time, this adds the period constraint, it becomes a one-to-one relationship (a company has only one employee named XX at a certain time ). In DOMAIN-DERIVEN design, this rule is as follows:

L define that the object traversal has only one traversal direction

L add conditions to reduce multiple associations

L eliminate unnecessary associations

Entity

Some objects are defined by only their attributes, and their attributes often change over time span. However, some attributes remain unchanged and can be uniquely identified. Such an object is called entity, that is, an object. For example, if a person is an object, can his name uniquely identify him? The answer is no. He may be James, and his nickname may be super Ming. At work, he may have an English name, Kevin, and a QQ account may be big wolf. His name is just a person's attribute, attributes can be changed in time and space span, but his ID card number is unique and can uniquely identify this person. When processing entity, the selection of identifiers is crucial because entity often involves serialization and storage, and the unique identifier often affects the serialization scheme.

Value Object

Value object is a value object. It only cares about the attributes of the object. during the life cycle of the value object, attributes cannot be changed. To change the attributes of the value object, replace the attributes of the value object instead of modifying some attributes of the value object. For example, an address object contains attributes such as province, city, district, and street. The customer object has an address object. In most cases, this object does not need to be modified. Even if the customer moves, the address is changed. You only need to create a new address object to replace the old one. Using value object can greatly optimize the system. For example, in the task system, each task has a description text description, which belongs to the value object completely. Each task object has a description attribute, which can be referenced rather than copied here, because we have defined that the description cannot be modified, it is thread-safe. However, when there are millions of task objects in the system, memory optimization is exhausted. In fact, this modeling is completely in line with the relationship in reality. It has been optimized from the modeling level, and the design and development are closely linked and there is no gap between them.

Service

Sometimes an object is not a thing, but a series of special actions. It is used to coordinate the relationship between objects. Generally, it is named after an activity. Generally, its name is a verb. Service should be stateless. In our task system, there is a service called task_generator, which is responsible for generating correct new tasks for the user. He generates a task for the user according to the context of the parameter. For example, if the user enters the system for the first time, he needs to initialize some basic tasks for the user, such as generating three series of mandatory tasks. If the user has just completed a task, task_generator only needs to generate subsequent tasks for the task. Task_generator only contains a series of actions, such as task definition repository, task object, and user context data. Task_generator is stateless, so it is not a problem to finish multiple threads. The only competition lies in that the task warehouse is global and the read/write lock is used for implementation. Task_generator. To put it bluntly, we just encapsulate a series of operations into objects.

Module

We often mention the advantages of the module. From the first day, we came into contact with the programming teacher and told us that software programming needs to be managed separately. This is the root idea of the module. The principle of the module has always been discussed, such as high cohesion and low coupling. In domain_deriven design, module provides two cognitive methods:

L you can view internal details within the module without any external factors, because the module is highly cohesive.

L The relationship between modules can be viewed outside the module, without the implementation details of the module.

Domain_deriven
Design also stressed that module refactoring has a greater impact than object refactoring. Therefore, we should be cautious about module refactoring, and the module should be of medium granularity. fine-grained modules are often not suitable, it is best to ensure that the operation and data maintenance objects are in the same module.

In our task system, the achievement system is integrated, and the two are two independent modules. The only connection is the user's behavior base (such as playing the blame) the tasks and achievements are accumulated. Database/table sharding is also an independent module. The logic layer maintains a task_service to map the objects in the logic layer to the data in MySQL.

Question

DOMAIN-DERIVEN
There are many guiding modeling modes in design. Since not many of them have been in the project, many of them are not very thorough. The biggest question at present is that they are in the modeling stage, what are the principles of object abstraction? Especially when there is no clue about the complexity of logic, what is better begin?

I have always thought that software and architecture are very similar, but software is more responsible than architecture, because software is invisible. Why is the software so complicated !!

DOMAIN-DERIVEN
Design should be a good direction. Quote Lao Tzu's sentence:Wu Sheng has an issue, And no!

The last half of the sentence is more philosophical: to have nothing to worry about.