Brief discussion on key points of software architecture design

How to better software architecture design, this is a software engineering field of an eternal key topic. Over the past few decades, the International Software engineering community has made great strides in software architecture design, and a large number of books, articles and literatures record the mature experience and achievements in this field. Software architecture design is often a very complex work, involving a lot of details and aspects, can be discussed in a very large number of topics. Limited by the space limit, the following can only be based on the author's personal understanding, the selection of software architecture design of individual points, combined with the current popular agile software engineering ideas, with you to share their experience in software architecture design and experience.

Architecture determines success or failure

Software architecture is the main structure and principal contradiction of software PRODUCT and software system design. Any software has a structure, even a short HelloWorld program. The success of software architecture design determines the success or failure of software product and system development. Software architecture has its own attributes and characteristics, which determines the complexity and difficulty of software architecture design.

In the past few years there has been a saying (management proverb): "The details determine the success or failure", which is only half the sentence. Details are really important, and many projects and products are lost in the implementation of the details. On the one hand, tactical details are important, but on the other hand, the overall strategy is equally important, we can say: "Strategic decision success or failure." Strategic failure, like the next set of Go, part of the next beautiful, again fierce, if the disregard of the market, not even enough of their own, and the official son (details) the chance to win? Must be a lost.

Similarly, the correct software architecture design should include both strategic global design and tactical detail (critical path) design. There is a misconception that software architecture design is finished by dividing layers and packages, drawing a rough sketch of the outline. This "armchair" type of architect behavior is very harmful. In fact, since the software architecture is the main structure of software architecture, hidden engineering, load-bearing walls and key parts, then the software architecture is bound to implement the actual algorithm and code, not only to have the implementation code, but also to include this part of the framework to test the code to ensure high-quality, A schema that meets the requirements of various functional and non-functional quality attributes. In addition to complete the concept, model design, software architects must participate in the actual coding, testing and debugging, as a real hands-on practitioner, this has become the Agile software engineering advocated by the mainstream culture.

Two schemas

In our day-to-day software products and systems development, we actually encounter two, two-part software architectures, the software architecture for the application part to be developed (the "Application Architecture"), and the existing infrastructure ("infrastructure"). These two parts of the architecture are interdependent and mutually reinforcing relationships that collectively form the architecture of the entire software product and system.

Examples of infrastructure include:. NET and Java EE and other mainstream infrastructure platform and a variety of public application frameworks, from the Basic library API, object model, event model, various development and application of extension rules, and other content. Only when we are familiar with the construction details and application mechanism of the infrastructure can we effectively develop high quality and high performance upper level applications. However, to develop an end-user-oriented software application system and product, it is obviously not enough to master the knowledge of computer advanced programming language and the knowledge of basic platform architecture and API, we also need to design high quality application software to meet the requirements of customers based on the type and characteristics of customer application.

Familiarity with OOA, Ood abstract modeling techniques, design principles, and architectural and design patterns can help us to better understand and leverage the infrastructure of the underlying platform, as well as to design and develop higher-quality application software architectures.

Design and development of risk-driven, agile iterative architecture

Software architectures evolve over the life cycle of software products and systems, often more than one project, one release, and possibly years long, so software architecture is an extremely important asset for both customers and developers.

What kind of development process should be followed in the design of software architecture? Or is there a better, mature software architecture design and development process? The answer is that the 21st century software architecture design should take the advantage of agile iterative development methods and methodologies. Unlike traditional approaches, agile iterative development advocates the evolution design of software architecture (evolutionary), a software product or system architecture that is built and perfected in the development lifecycle through multiple iterations and even multiple releases.

A good software architecture is not an overnight program. In the framework design and development process, we should try to avoid waterfall thinking, through an "architectural design phase" to complete the system architecture design and even detailed design, and then according to the architecture drawings and models, in the "coding implementation phase" netizens coding and implementation of the architecture. The mistake of this traditional approach is to think that software architecture is the model on the drawing, not the source code that really can be executed with high quality. Decades of software engineering practice has shown that no code implementation, testing, user-confirmed architecture design, often there will be unreliable assumptions, speculation and excessive design, over engineering, very easy to cause waste and rework, resulting in higher failure rate.

Risk is any potential factor and problem that may hinder and lead to failure of software PRODUCT/system development. Software architecture is the main contradiction and technical risk of software product and system development, and the quality of software architecture determines the quality of the whole software system and product. Uncertainty is often one of the biggest potential risks in software architecture design. Therefore, the design and development of software architecture should follow the principle of risk-driven, maintain a list of risk issues throughout the development lifecycle, and as the iteration progresses, the most important architectural risks are resolved and dealt with in the first place, based on real-time dynamic changes in risk, and then the secondary architecture risks are resolved and addressed in turn.