Software Architecture consistency

In the software design stage, we must unify the architecture ideas and Development specifications of team members. The following is a recommendation Article : Http://www.agiledon.com /? P = 441. The full text is as follows:

The importance of consistency to software is mentioned in the book The design of design, the latest masterpiece of Brooks. He believes: "consistency should be the foundation of all quality principles. A good architecture should be direct. People can guess other parts after they have mastered some systems ". This so-called "a glimpse of the leopard" requirement is actually to maintain style consistency.

Style consistency

Many software companies develop code specifications that comply with their own situations and industry specifications. For example, the requirements for naming, format, and many other styles. The consistency of this encoding style is relatively easy to implement. The consistency mentioned by Brooks is more about the consistency of the architectural style. So what is architecture style )? In application architecture guide 2.0 written by Microsoft, the architectural style is defined as a set of principles and is a coarse-grained pattern that provides an abstract framework for the system family. Architectural style can improve design, promote reuse, and provide reliable solutions for common problems. Mary Shaw's definition of the architectural style is even more obscure: "The architectural style defines the system type according to the schema of the structure. More specifically, the architectural style defines the vocabulary of components and connector types and a set of constraints on how they are combined ." Apparently, Mary Shaw believes that architectural styles define the structure of architectural components and the principles and constraints they must follow.

The architecture style may be applied to some architecture models. However, before using the architecture model, you must first distinguish the category of the system. For example, if the system is an enterprise application with complex business needs, the domain model should be selected for the domain layer ), ensures system reusability and scalability by effectively utilizing objects, components, and services. Once the domain model is selected, the transaction Script Mode should not be used in other modules of the same system. Otherwise, we violate the style consistency.

We often use the selected architecture style as the core framework of the entire system architecture. Understanding the architecture style helps you understand the entire software system. For example, for a data analyzer system, its core logic is input data streams, output data streams, and analysis.Algorithm. Because the analysis algorithm filters and filters data streams, the architecture style we select is pipes and filters. Then, when understanding the data analyzer architecture, as long as you master the core idea of the pipeline-filter mode, you can quickly grasp the core of the system architecture. This facilitates the extension of system knowledge and ensures the consistency of the entire system.

Of course, the choice of architecture style will lead to different solutions due to different concerns. For example, from the perspective of deployment, we may need to select the physical architecture of distributed deployment. For the same system, because of the need to consider message transmission, we may also choose the message bus mode. This is not in conflict with the style consistency. We only need to ensure that the style is consistent on the same aspects of attention.

Solution consistency

Style consistency is at the software architecture level, similar to ensuring solution consistency. In the entire system architecture, the solution must be consistent, otherwise it may lead to chaotic architecture and code generation. So how can we ensure the consistency of the solution? Prior to system architecture, we must develop architecture principles that are widely accepted by team members based on the system and team situations. For example, we can develop hierarchical guiding principles for the system. For the domain layer, we follow the requirements of DDD to clearly define the entity, value object, aggregation root, service, factory and resource library for the domain model, and clearly indicate the characteristics they should possess. We require that the application service layer should not contain any business logic. It is only responsible for message transmission between the UI and the domain layer, and can call the data verification, cache, and security functions of public modules in the infrastructure. We require that the application service layer should not retain the status of the Business Object, only be responsible for coordinating application activities, and require all open application services to be defined as interfaces.

After such an architecture principle is formulated, we can unify the system solution. For example, following the previous layered guiding principles, we can obtain the following Unified Solution for the Domain Layer:

If we do not ensure the consistency of the solution and establish a unified architecture principle for this purpose, the team members can select the solution as they wish. Even if a developer chooses the optimal solution, the entire system may be in disorder due to a variety of different solutions in the system. For example, in a system I have seen, there is an inconsistent database access solution. In the same system, module A uses the JDBC template of spring to access the database, while Module B directly uses JDBC. In this system, Module C uses JDK map to cache frequently read values, while Module D uses open-source ehcache as the cache.

In order to ensure the consistency of the solution, in addition to the need to develop a unified architecture principles in advance, the style consistency mentioned above can also provide unified guidance and constraints. In fact, we can understand the consistency of solutions as an implementation of style consistency. In addition, collaboration and communication between team members, as well as necessary architecture reviews andCodeTo some extent, different solutions can be avoided.

Form consistency

The purpose of maintaining the formal consistency of the system architecture is often the intention of the architect to maintain the simplicity of the architecture. One principle that best reflects form consistency is "convention is better than configuration ". This so-called "Convention" can be understood as some constraints on the implementation of the Framework. Based on the predefined default rules, we can use reflection technology to create objects, collaborate with objects, and even apply objects.Program. The key to "Convention is better than configuration" is that it specifies formal consistency. Taking Ruby on Rails as an example, by establishing the directory structure and naming rules of model, view, and controller in advance, developers are forced to divide the system by MVC and strictly abide by the framework-based specifications. When the program runs, rails assembles the separated parts. By default, the assembly process follows Naming Conventions and Conventions. In general, no external metadata configuration information is required. Is the MVC Architecture of rails:

After the client sends a request to the server, dispatcher will parse the request URL and determine which part of the request should be sent to the application, and how to resolve this request. After finding the correct controller and action, you can use this action to process the request. Action can view the data carried in the request, interact with the model, or call other actions. Finally, Action prepares sufficient information for the view, and the View displays the required information to the user. Because the consistency can be maintained in the form, the framework becomes simple and the components involved can perform their respective duties with clear responsibilities and clear intentions.

This form of consistency is based on a simple idea that limited constraints are easier to implement and follow than full openness. Just as society always has a set of rules widely recognized by people to constrain the behavior of every citizen, otherwise the whole world will be messy. The essence of formal consistency lies in the integrity of concepts, and its foundation lies in conventions. The complexity of the architecture is that we cannot make correct decisions for chaotic systems. If we can abstract the overall concept for the scenario we want to solve, we can simplify the model to the maximum extent, so as to provide a consistent agreement. Rails simplifies the Web architecture by using the existing MVC pattern and the consistency between Conventions and Conventions on the form. If we observe the directory structure of Maven, we will find that Maven also proposes its own conceptual model for dependency management, and formally defines the architecture consistency:

A Concise architecture often represents a unique beauty, while a consistent architecture brings harmony and balance to the software system. The consistency of the architecture style can ensure the unification of the system architecture. As long as the designers grasp the Style Characteristics of the architecture, they can grasp the "God" of the system, so as to promote the understanding of the system architecture. The emphasis on architecture style is also conducive to the reuse of architecture-level resources. By analyzing the problem domain, we can determine which architecture style it should belong, you can find the appropriate architecture principles, models, or existing platforms and frameworks. Consistency of solutions can avoid chaotic software architecture, promote communication and collaboration between team members, and avoid waste of resources caused by inconsistent solutions. A consistent solution can also ensure the quality of software, because many potential risks and defects are caused by conflicts caused by different solutions. Form consistency is a prerequisite for simplification, and can ensure the unification of system concepts. by abstracting and simplifying the conceptual model and formulating consistent architecture conventions, the entire architecture system can be simplified, reduce the difficulty of implementation.