Architectural patterns, also known as architectural styles, are the result of well-chosen tactics, and these fixed results (patterns) are universally useful and reusable at a high level of abstraction. With architectural patterns, architects can borrow and reuse the experience of others to see how similar problems have been solved by others.
But don’t think of a pattern as a hard and fast solution, it’s just a way to solve a problem. MartinFowler once said, “the difference between patterns and business artifacts is that patterns make you think.”
Evolve the delivery lifecycle
The industry has developed various software lifecycle models that put architecture in place, typically the evolutionary delivery lifecycle model.
In the lifecycle model, architectural design begins with a preliminary requirements analysis and proceeds through step-by-step iterations (illustrated by the reverse arrow in Figure 1).
On the one hand, you can’t start designing the architecture until you understand the system requirements. On the other hand, you don’t need to wait until all the requirements have been gathered to start designing the architecture. Architecture is “shaped” by “architecture-driven” factors, which are the few key, highest-priority business goal quality requirements. Architecture, determined by a few key requirements and in a basically stable state during iterations, serves as the infrastructure for evolution.
2. Attribute-driven design
The above model emphasizes the establishment of software architecture first, and then takes the architecture as a skeleton, iterating on the skeleton and gradually growing into a flesh-and-blood system. Attribute-driven Design (ADD) is a method to define software architecture, which bases the decomposition process on the quality attributes that the software must satisfy.
The inputs to ADD are: functional requirements (typically expressed as use cases), constraints, and quality requirements (a set of system-specific quality scenarios).
The steps for ADD are as follows.
(1) Select the module to be decomposed
Often the entire system requires all of the above inputs to be available (constraints, functional requirements, quality requirements). Start with the system, break it down into subsystems, and further break the subsystem down into sub-modules.
(2) Module refinement
Architectural drivers are selected from a specific set of quality scenarios and functional requirements. Rather than looking at all requirements equally, the less important ones are met only if the most important ones are met, which prioritizes architectural requirements. Select architectural patterns that satisfy the architectural drivers and create (or select) patterns based on the previous tactics. The goal is to establish an overall architectural pattern consisting of module types. Instantiate modules and assign functionality based on use cases, represented with multiple views. Define interfaces for submodules. Validate and refine the use cases and quality scenarios so that they become constraints on the subpatterns.
(3) Repeat the above steps for each module that needs further decomposition.
3 Organize the development team by structure
After the first few levels of the architecture’s modular decomposition structure are relatively stable, these modules can be assigned to the development team, resulting in a working view. Like software systems, development teams should strive for loose coupling and high cohesion. That each module form their own small areas (specialized knowledge or expertise), and interfaces with other modules is clear, in this way, different modules are assigned to the different development teams, can reduce the communication cost between the development team, and within the development team, because it is dealing with the problems in the field of small, easy to set up effective communication mechanism, If members have background knowledge (or training) in this area, share decision-making information.
At the same time, the project plan can be further refined based on the division of labor after the framework is determined, especially the time points provided by the interface should be well planned to ensure the overall coordination of the project development.
4 develop skeleton system
There are two cycles in the evolutionary delivery lifecycle model. The first cycle is iterative development of the software architecture, and the second cycle is iterative development of the deliverable final version based on the architecture. Developing the skeleton system is the first step in the second cycle. This step is to develop a working prototype (skeleton system) using the architecture as a guide. In the process of skeleton system development, we should pay attention to the full negotiation of interfaces, so as to avoid forcing the first part to meet the following part’s unreasonable interface requirements. Once the skeleton system is complete, incremental development can be done on top of it until software development is complete.
5. Use commercial components for development
Patterns are solutions to specific problems. Therefore, according to the characteristics of requirements, corresponding patterns can also be selected to design architecture, and the use of commercial components corresponding to this pattern for software development. For example, object-oriented distributed systems can be developed using J2EE/EJB.