Ten, refine and merge
It is necessary to refine and merge it for an initially established model (analytical model or design model).
Context
Establish an architectural vision, define the main design strategies and achieve ideas for architectural design. The principle of applying a layered is structurally divided on the entire software, and the responsibility of different parts of the structure is defined. Now, we need to improve the necessary improvements to the initial completion model.
Problem
How do we improve the initial architecture model?
Solution
Activity to the model can be divided into refining and combining. Let's start from the beginning.
First, our initial architecture model on your hand has included the content of the general principles (see architectural vision mode) and the layer structure (see hierarchical mode). Now what we have to do is divided into different coarse granular components based on demand and architectural principles. The coarse particle size assembly is derived from a business entity in the analysis activity. Combining a strong correlation business entity form a collection. There is an intricate relationship in the collection, and the collection provides a service interface to the outside. Such a collection is called a coarse granular assembly. The realization of the external interface and the interior of the coarse particle size assembly is distinguished. The coarse particle size assembly has a lot of JAR files on the Java platform, the DLL file on the Windows platform, and even ancient .o or .a files can be the form of a coarse particle size assembly. Design excellent coarse granular components should just complete a function, this is its main distinction between the subsystem. A system may include accounting subsystems, inventory management subsystems. However, it is not significant of providing accounting coarse particle size components or inventory management of coarse particle size components. Because such coarse granular components range is too wide, it is difficult to play a reuse value.
The coarse particle size component can be (possibly necessary) across the level. The crude granular assembly has a persistent behavior, with business logic, requires a support of the layer. This looks like this, the axial direction and the level of the hierarchy is perpendicular to each other.
The coarse granular assembly comes from the demand. The demand manual or the use case model will be the basis for the development of coarse particle size components. After having a demand workpiece, we need to divide the needs, divide the demand into several functional groups so that we can basically get the corresponding coarse granular components. If the system is large, you can make a segmentation of the function group. This depends on the range of coarse granular components. Over-range, it will cause the coarse particle size assembly to be not easy to use. The user needs to understand the complex relationship between different coarse granular components, and the final result will also contain a large number of components and complex logic. Excessive range, it will cause the coarse particle size assembly to be reused, causing a coarse granular assembly as a subsystem.
Suppose we need to develop a human resource management system. After organizing, its demand is roughly divided into such parts:
◆ Organizational structure design and management: including employee duty management and management of employee department.
◆ Management of employee materials: including basic information of employees and simple assessment information.
◆ Management of daily transactions: including attendance management and payment management of employees.
For the first two function groups, we believe that establishing a coarse particle size component is relatively appropriate. But for the third function group, we believe that the range is too large, because it is divided into attendance management and wage management. Now we get four coarse particle size components. They are organizational structural components, employee data components, employee attendance components, and employee wage components.
After getting a coarse particle size assembly, our work needs to be divided into two parts: the first part is the relationship between different coarse granular components. The second part is to define a business entity or define a fine particle size assembly based on the coarse particle size assembly.
The relationship between different coarse granular components is actually an external interface of the coarse granular assembly mentioned above. If possible, define a one-way association between the coarse particle size assembly (as shown in the figure above) can effectively reduce the coupling between the components. If you must define two-way associations, make sure the consistency between the two parties. In the figure, we can see clearly that the organizational structure is in the bottom, and the employee data depends on the organizational structure, including the department of employees from the organizational structure, as well as employee duties. For attendance, wage components, the necessary information needs to be obtained from employee materials, as well as information in sectors and positions. There are two ways to associate definitions here, one is to obtain department and job information from the organizational component from the organizational component, and obtain additional information from the employee data, the other is as the above figure, the attendance component is only from employee data components. The information is obtained, while the employee data component reuses the delegate, obtaining information from the organization and position from the organizational structure. The advantage of the second approach is to block attendance, salary components, and maintain the consistency of information acquisition. It is only a simple relationship between components. The relationship in reality cannot be so simple, but the basic idea of processing is the same, that is, simplifying the relationship between components as much as possible, thereby reducing the coupling between them. Considering the needs of another, on the basis of the original system, we increase the accounting subsystem part, with a coarse particle size component to conduct cost analysis of the department and employee. On the basis of the original model, we increased hierarchical considerations. From the figure below, we can see that organizational components have played its reuse and is used by cost analysis components. Considering (see hierarchical mode) from the layering, we divide the organizational component to the tool layer, and divide other components into the domain layer and perform sub-system levels in the domain layer. From a point of view, this approach is similar to the modeling process of analysis model. In short, in this process, the most important thing is to define the relationship between different components. Although this analysis is initial, blurred.
After obtaining a coarse particle size assembly model, we need further analysis to obtain fine-grained components. Fine-grained components have better reuse and make the refining of architecture design further. By Jacobson recommended, object-oriented software engineering (OOSE), we need to identify critical entities from the target domain of the software, or are nouns in the field. For example, employees, sectors, wages, etc. in the above examples. Then determine which coarse particle size components should be at home. First identify fine-grained components or first identify the coarse particle size assembly and there is no fixed order.
The originally obtained component model may not be perfect and need to be modified. There may be too much class in a component. It is too complicated. We need to further refine it, divided into thinner components, and maybe the classes in a component are too small, and other components are needed. Maybe you will find that there is a repetitive element between the two components, and can extract the common part of the commonality to form a new component. The process of component analysis does not have a standard practice, you can only analyze according to specific cases. In the end, you may worry about the ownership of several classes, don't waste too much time on them, don't exist in the best model.
The final model will explicitly include several coarse granular components that have been removed. The relationship between the coarse particle size assembly will also be redefined. If this time, there is still a complex relationship between the coarse particle size components, which may mean that your business logic is more complicated, so this part requires you to put more energy to handle. Of course, you can reduce the degree of coupling between different components through some techniques. There are several referred measures here:
The first method is to use a FACADE mode (in the hierarchical mode, we mentioned an appearance mode). As shown in the figure below, the newly introduced BusinessFacade class acts as an appearance, isolates the caller and complex business class. The caller does not need to know the complex relationship between the business class, it can make business processing, thereby greatly reduced The coupling between the caller and the business class. This method is often employed in practice, suitable for use in components of internal relationships, and is also suitable for use in the case where the traffic layer is released to the representation layer. For appearance mode, we can provide parameters in the business method of the BusinessFacade class to deliver data. This is special for some scenarios for some data. If the data type is more, the parameter class or value class can be used to achieve the purpose of data transfer. The second method is to use the command mode, which also comes from the design mode. When processing parameters, command mode uses a series of set methods to set parameters one by one, and finally calls Execute () to perform business logic. The advantage of command mode is to provide a unified interface for the caller. The caller does not need to care about the specific business logic. What he needs to do is to set the data, and call the execute () method. If you encounter business logic, more parameters are used, the call set method is too troublesome, or a setValues () method can provide multiple parameters. Of course, this mode also has its weaknesses, and if the business method is too much, then the corresponding COMMAND class will increase. This is what we don't want to see.
In addition to the two methods described above, it is also possible to reduce the coupling between different components such as a factory model, a business delegate mode. It should be appreciated that different design modes have their different context environments, in architectural models (and analysis mode) help optimize design, but please pay attention to the context environment, misuse or abuse modes can result in design. The mistake.
The method described above can be hidden to the caller with the method of reducing the coupling between the different components. This is a very critical for reconstructed activities (see Refactoring mode) because it can effectively mitigate the change in components to other components when reconstructing components.
Improvement is the first step in modification of the model. The completed model basically represents the final software. But if we carefully check it, we will find that the model still has problems. The problem at this time is mainly reflected in the design model too much. If the refinement makes the model complicated, the merge is to make the model simple. Don't think that these two work are mutually exclusive. Through these two activities, the model can be greatly improved.
Remember the simple principles mentioned in simple design patterns? Before entering the discussion below, make sure you can understand the simple principle, this is one of the agile core principles.
In the above, we mentioned the use of some design patterns, and in the entire agile architecture design, we also discussed the model. And in many cases, we are actually solving some simple problems in inappropriate use patterns. Therefore, before using the mode, we should review the relevant parts on the demand manual (or the use model model) to determine if the mode is required.
When the persistence mechanism of a design software, I chose the DTO (Data Transfer Object) mode as the implementation mechanism of the persistence layer. The reason is just to see this mode on the night before, and I feel that it is cool. It seems that I made a model syndrome (after learning a pattern, I want to use it to use it). After spending a lot of time learning and implementing this mode, I found that this mode is not able to play it. The reason is that the context environment of the mode is not suitable for use in the current software, which only needs to be implemented with JDBC. After using the mode, it becomes complicated. Worse, I have to explain this model to the developer, and I have the exquisiteness of this design pattern. But the result is disturbing. Developers obviously don't understand what role in this mode is here. Finally, I dropped this mode and the design was simplified. Similarly, there are also various exemplary examples, especially in database access, thread safety, consistency, etc. These problems often take a lot of time to handle, but their value is not high, especially small systems. Of course, these problems must be considered when designing some large systems.
When using the design mode to integrate different components, we also need to merge the behavior of the components. The same behavior between different components is merged into one component, especially those that have a very complex relationship. This can hide the complex relationship to the inside of the component and simplify its external interface.
It is difficult to evaluate whether the design has been completed. There are two different extremes here. Excessive time spent on initial design, and overreasing. Too much time spent on the initial model does not necessarily get perfect models, the opposite, may also cause the design model to make a mistake of design model due to the behavior of the designer's drill angular tip. In too frequent iterations, it is equally good for improvement models, because in fact, you are not improving model, but in changing models. Please distinguish these two completely different behaviors, although they seem to be similar. In Refactoring mode, we will further discuss iterations and model improvements.
One judgment method is to invite the coding person to evaluate whether the design is completed. The design model will eventually be handed over to the coding person, and guide the development of the coding personnel. Therefore, if the coder does not understand the model, this model is designed to see again, and there is no great role. On the other hand, if the coder believes that the model is sufficient to guide the development, then what else is it necessary to paint the snake? Different levels, different experiences of codents are different from the requirements of the model. In our work, the model of senior developers and the development of newcomers is not the same. For senior developers, you may only need to use the appearance mode between the component A and the component B, and he can understand the meaning of this sentence and start developing, but for the experienced developers. It is necessary to describe the beginning of pattern theory. For them, the design model must be sufficiently detailed enough. Settings need to be designed to describe all classes, methods, parameters, and functional descriptions.
Review is an important means of avoiding errors in design models. It is highly recommended to introduce review activities during architecture design. Review has a major help to avoid design errors. Review should focus on the relationship between classification of coarse particle size components and coarse particle size components. As the subsequent Refactoring mode and stability mode are depicted, the stability of maintaining the coarse particle size assembly helps reconstructing behavior and contributes to the improvement of architectural models.
