Entity issues in system development

In the current work, it is mainlyCommunity), Some colleagues asked, in the system, the data entity is now independent, in the development, in addition to the function call, I didn't feel any other advantages in using the object transfer method?

In fact, from multiple aspectsCodeIn itself, the most direct feeling is that object objects are transmitted in the method parameter list during method calling, so as to avoid the annoyance of "code earthquake, generally, changes in business requirements will lead to changes in the business object itself, isolating the changed items independently. If the method parameters are all processed in the form of passing values, when a business requirement changes, you may need to modify the parameter list of A method. As a result, all classes that reference this method will change, and some users may say that the method can be reloaded, this method is also acceptable, and the code is very bloated due to the amount of heavy loads.

For the design field of "DDD:

Domain description:

Simply put, each softwareProgramIt is related to the activities or interests of users. The main environment for using programs is called the "field" of software ".

Various business logics in the field constitute a multi-collection of software. For example, in the banking and financial system, domain logic involves operations such as account opening and transfer. You may say that website programmers seldom access the banking system. Such examples are not simple enough. To give a more common example, programmers should have been familiar with them.ArticleManagement System. The operations such as pin and refine in it are domain logic. In this case, it seems that the action corresponding to the use case is domain logic, but the answer is no. For example, saving articles in the article management system is often not domain logic, because it is only a persistence-related action, it is purely technical implementation, but the deposit of cash in the banking and financial system is usually classified as domain logic, because it is what we often say about deposits and has a clear business meaning. Seeing this, we seem to have some faint. Here we will provide a rule to determine whether it is a domain logic: whether this logical action has a clear business meaning or whether it is business-related, it's not just about technology.

Only the technical implementation means can be removed from the domain issue to ensure that the domain itself is refined, so that programmers can concentrate on the domain issue itself, rather than being full of technical implementation means.

People who have just made a system analysis usually make a mistake and place their eyes on the storage field, rather than focusing on the business field and technology to achieve a higher level to view business needs. It is often considered that this is only to change the value of a data table field. That is to add more tables .....

Composition of fields:

According to Eric, the role composition in the field is generally divided into the following five types:

Entity: an object with a unique identifier.
Value Object: the object without a unique identifier.
Factory: defines how to create an object.
Repository: Manages entity sets and encapsulates their persistence processes.
Service: operations that cannot be assigned or encapsulated on a single object.

 

the concept of entity is easy to understand. There are many such examples. For example, everyone can be seen as a "distinctive" entity, the reason why I use the word "uniqueness" is to emphasize that the entity must be uniquely identified. Even if we think of identical twins, they can be separated by some identifiers, for example, you may raise your fingerprint. What if you have no hands on the disabled? In this way, we can also use DNA detection. Of course, these are all just a joke. In actual programming, we generally use an auto-increment number as the identifier, for example, you can use an auto-increment field when saving an object in the SQL Server database. It should be noted that if you want to determine whether two entities are equal, you cannot determine based on the attributes of the entity. It must be absolutely dependent on the entity identifier (Unique Identifier between entities) although you and the present you have changed more or less in height, weight, age, and other important attributes, you are still you, because your DNA will not change because of these attributes. These seem to have some philosophical taste. For posts on common forums on the Web, the changes in the Entity Data of the posts themselves do not affect the unique logo of the posts. However, it is topped and refined, or to the deleted state. The unique identifier that identifies the object will never change. In turn, the unique identifier of the object can be used to find the relevant data of the object.

The meaning of the value object is relatively vague compared to the object. Many people prefer to call the data transmission object a value object (the data transmission object is different from the value object we mentioned here) this gives people a lot of ambiguity in their understanding of value objects, and the examples of value objects are not as straightforward as the objects. Literally, the value object does not have a unique identifier. In most cases, the value object remains unchanged. Therefore, the system does not need to track them in real time and instantiate a value object, if you don't need it, destroy it. But when do you use a value object? Which attributes are classified as value objects? What is the role of a value object? These are all worth considering. Generally speaking, when we conduct Domain Modeling, we give priority to the unique identifier and the information that is often used to retrieve objects as the attributes of objects, while other information is divided into other entities based on relevance, it can also be divided into value objects. For example, in a CMS system, for an article entity, the article number and the article title should all be attributes of the article entity, for the start time of the validity period of an article, the end time should be placed in an independent value object, where only the start time or end time is used, or both the start time and end time exist or do not exist at the same time, which indicates different logic meanings. The rational use of value objects is helpful to shield the complexity of some related logic, you can also keep the object concise. For another example, when uploading a video, there is usually a Video category, which is the unified maintenance of the entire website. users do not need to maintain this category, and relatively speaking, after a category is published, its value is relatively stable and there is no need to have a unique object identifier. Because it is unique in the system, it can be designed as a value object, when you need to upload a video, you only need to read it.

The factory is much easier to understand than the former two. After all, the name can reflect its responsibilities, that is, to create an object. Since the object is created, can we instantiate one directly? A simple scenario is acceptable, but factories often bring huge benefits. Simply put, they block the complexity of object creation. A group of related objects should be considered as a whole, access to any of these objects should also begin with the overall "root" (usually the most important entity in the whole as the root). Therefore, complicated Association will inevitably make the creation process as complex as possible, can we assemble objects in the constructor of the "root" object? In simple cases, complicated and inappropriate, such as assembling a car, it is usually done by the Assembly worker and robot in the factory. If we complete the assembly in the constructor of "heel", it is similar to the Assembly worker and robot in the car, this is of course unnecessary. Once a car is assembled and manufactured, it is unnecessary to assemble workers and robots.

the concept of warehousing is similar to that of data access objects (DAO), but it is not the same. A big difference between the two is that warehousing has the concept of "root, data access objects are usually divided by tables in the database. The main purpose of using warehousing is to query and persist objects in the field (of course, it is not necessary to use a database for persistence, but also to write files on a disk and use them in reverse order ), domain objects tend to have complex aggregation relationships. To ensure the invariant, the root concept is introduced. Access to a child object in the domain object must be guided by the root. This may not be easy to understand. I would like to give a simple example: cars and tires can be regarded as the aggregation of objects in the field. Cars are the root of the aggregation. If we want to ask about tires, it must be done through the car navigation. Why? Because there is a constant between the car and the tires: a car has four tires. If the client is allowed to directly access the tires, it is difficult to prove that this logic is not broken. In community development, for example, the discussion topic and the reply of the discussion topic in a group, we usually enter a group to see the discussion topic related to this group, after opening a topic, you can see the post related to the topic. The relationship between the topic and the post under it is an aggregation relationship. If post leaves the topic, there is no meaning, its access must first access the topic and then see the post, so that you can understand the specific significance of this post. If you can access this post externally, other pages directly access this post, and some zhuyun. It also destroys the relationship between the topic and the post object.

The term "service" has been used many times. However, most of the services mentioned previously are technically specific and belong to the application layer in terms of hierarchy. Generally, it is something like sending an email successfully after registration. The service in the domain-driven design is not a concept of this category. It emphasizes the relationship between entities, instead of purely technical means. For example, in the CMS system, if an article is added to the essence, the author's experience is plus one. This logic involves a number of entities: Article entities and author entities. The logic of experience value plus 1 is redundant in both the article entity and the author entity. Therefore, it is necessary to abstract a service layer on the entity for processing. Someone may ask: Can we put this logic on the traditional application layer? In most cases, this logic belongs to the domain logic rather than the application logic. If it is placed at the application layer, the domain logic is leaked, and the domain layer becomes a decoration, however, there are also exceptions. Sometimes it is difficult for us to identify whether a logic is a domain logic or an application logic. It is no problem to add this logic to the application layer at this time, if it is found that it is more appropriate as the domain logic in the future, it will not be too late for reconstruction.

After writing it, let's look at it. It seems that it can only be called graffiti. The field-driven design depends on your own experience.