How to design the software architecture?

How to design the software architecture?

Purpose of Software Architecture Design

For outsourcing business projects, the purpose of software architecture design is different from that of Product Projects. Here we mainly discuss the purpose of Software Architecture Design for outsourcing projects.

1. To provide the foundation and specifications for large-scale development, as well as the provision of reusable assets and large-scale development of software systems, there must be a certain foundation and follow certain specifications, this is both a requirement of software engineering and a requirement of the customer. In the architecture design process, some public parts can be abstracted to form public classes and tool classes for reuse.

2. Shorten the project cycle to a certain extent, and shorten the project development cycle by using the framework provided by the software architecture or reusing components.

3. reduce development and maintenance costs, reuse and abstract a lot, and extract some public parts that developers do not need to care about, in this way, developers can focus only on the implementation of business logic, thus reducing a lot of work and improving development efficiency.

4. improve product quality. Good software architecture design is the guarantee of product quality, especially for the non-functional requirements that customers often propose.

Principles of Software Architecture Design

The software architecture design must follow the following principles:

1. Meet functional and non-functional requirements. This is the most basic requirement of a software system and the most basic principle that should be followed during architecture design.

2. The principle of practicality, just as every software system must be practical when delivered to users and can solve user problems, architecture design must also be practical, otherwise, it will be "high to high" or "over-design ".

3. Meet the reuse requirements to maximize the efficiency of developers.

Several views of Software Architecture Design

We often ask a variety of questions when discussing what architecture design should do or when reviewing the architecture design. For example, how should developers record logs and how should transactions be controlled? How can we improve the efficiency of our developers, that is, to implement more functions with higher quality within the unit time? How can we meet non-functional requirements of customers? How can platform administrators in the production environment better maintain the system?

The above questions are actually the questions raised by different stakeholders of the software system from different perspectives. We need to answer these questions, we have to look at Software Architecture Design from different perspectives.

1. From the logic architecture perspective, from the perspective of system users, the designed software architecture can meet the needs of business logic and be able to handle more and more complex business logic requirements.

2. From the perspective of the development architecture, consider the problem from the perspective of system developers. The design architecture should be easy to understand, easy to develop, and easy to unit test, it is best to allow developers to develop functions with the least number of lines of code.

3. From the operating architecture perspective, consider the quality requirements during system operation, and pay special attention to the non-functional requirements of the system, customers often require that the maximum response time of the functional screen of our system be no more than 4 seconds, which can meet the needs of 2000 users online at the same time, role-based system resource security control, and so on.

4. From the perspective of physical architecture, focus on the environment in which the system is installed and deployed, for example, the most popular enterprise application service solution ibm http Server + WebSphere Application Server + DB2, webLogic + oracle.

5. From the data architecture perspective, the various systems we have developed today, such as MIS, ERP, and SAP, are basically operating on various types of data, data Persistence is very important to present a bunch of poorly understood data into data that users can easily understand and automatically process various data operations.

1

1. analyze requirements and understand business models (or Domain Modeling), and select key use cases.

Software requirements can be divided into functional and non-functional requirements from the perspective of users and developers, we must fully understand the needs, analyze the needs, and understand the business model from different perspectives and levels. Practice shows that non-functional requirements that we often ignore often lead to failure of the entire project.

The best way to understand business requirements is to perform Domain Modeling. Domain Modeling and requirement analysis are often performed alternately. Domain Modeling has the following functions:

◆ Explore complex problems and clarify domain knowledge. Martin Fowler once said that the biggest benefit of adopting an object-oriented method is that it helps solve more complex problems. Domain Modeling itself, as a tool to assist in thinking, helps us keep our attention focused on the most important business concepts and their relationships, so that we can continue to deepen, the system analyzes and recognizes requirements. Domain Modeling is often a process from fuzzy to clear, from scattered to system.

◆ Determines the function scope and affects scalability. Any model is an abstraction of a program in the real world. This abstraction ignores some things, such as ignoring the relationship between object attributes and objects, however, these ignoring operations are often purposeful, and such ignoring determines the scope of the function. The model reveals the structure behind various functions. If the definition function is equivalent to taking a photo, Domain Modeling is equivalent to "pivoting", paying more attention to the internal structure of the problem domain, this is equivalent to a certain abstraction of the problematic domain. A good domain model not only supports existing functions, but also supports new requirements in the future to a certain extent, excellent scalability.

◆ Provide communication basis to promote effective communication. Domain Modeling usually uses UML diagrams as the presentation method, which provides convenience for our communication. Of course, sometimes words may be more suitable for describing problems in certain fields and can be used flexibly.

In our company's actual software development process, Domain Modeling often lacks this link, which may need to be further improved in future work.

Although we always hope that the architecture designer can fully grasp the needs, due to time and energy constraints, the reality is that the architecture designer does not have time to conduct in-depth analysis on all requirements, therefore, our strategy is to "use the steel with ease", that is, to spend most of our time and energy on the key requirements that determine the most important architecture. When selecting key requirements, you should note that high-priority requirements are usually from the user's perspective and may not be the real key requirements. How to determine key functional requirements is described in the "Guide to RUP practitioners? A. as the core of the application or implementing the main interface functions of the system, B. functions that must be implemented, that is, if these functions are not implemented, the developed software will lose value. it covers some aspects of the system architecture, but is not used by other important
The function covered by case.

2. consider all aspects of the software architecture from various perspectives.

The architecture design of the software must take into account all aspects. Based on the domain model, key requirements, and system constraints established in the preliminary work, the software must be designed from system users, developers, system administrators, deployment administrators, analyze and solve problems from the perspective of data administrators and other personnel. For example, if our operating architecture adopts the cluster mode, we must be careful with the use of cache and session. If our business logic requires us to operate multiple databases, we need to consider using the method that supports two-phase transaction commit.

This architecture design is complete only when all these issues are taken into account. What details should we design in each view is actually related to the process definition of the entire project. For example, if we have activities dedicated to the database outline design, we can focus only on the higher level of database features and the relationship between databases in the architecture design process, the Data Dictionary of each table can be designed in subsequent activities. However, if there is no such activity, we need to refine each column of each table, and the relationship between tables.

3. solve technical problems and problems

In the process of software architecture design, we often need to overcome some technical problems and difficulties. This is a task that requires a solid theoretical knowledge and rich practical experience. For example, how can we improve the performance of the entire system? How can we export extremely complex "Chinese-style reports" (which is generally much more complicated than reports produced by Western countries, and many open-source Bi frameworks cannot completely solve the problem )?

If a problem is indeed very difficult, you can go to Baidu or Google, consult senior technical staff or experts of the company, or hold a small technical discussion meeting, in order to improve work efficiency, you can try to find the answer in a mental way.

4. Hold architecture design review meetings for peer review.

Architecture Design Review is an extremely important part. I once described it as an escape from the "Seven Weapons" because many colleagues may raise questions or opinions at the meeting, in addition, many opinions are sharp, so we must accept them with an open mind and make a good record. The so-called "good medicine is good for disease, and loyal words are good for the ears ".

Before the review meeting, we need to complete a lot of preparations. It is best to prepare a concise e-briefing to list the most important issues so that during the review meeting, the meeting will not be aimlessly completed. The materials will be sent to attendees before the meeting, asking them to take the time to learn about how to control the progress of the Meeting and improve the efficiency of the meeting.

5. Implement functions on the designed architecture for key use cases to verify the architecture.

Verification of architecture design is also a very important task. There are many verification technologies. In our company, we usually adopt the sample format, that is, iteration 0 mentioned in XP, the sections mentioned in RUP. The advantage of this is that the architecture can be effectively verified from the perspective of the actual product, and the cost can be saved compared with the discard prototype verification technology.

This sample is by no means a piece of code that we use for experimentation when solving architectural design problems, it is a complete implementation of a key use case that conforms to the architectural design and a series of standardized deliverable Code and related documents. At the same time, this sample can be used as a teaching material for you to explain or train the architecture, or as a blueprint for developers to use this architecture for development, or even just copy and paste it, add a simple modification.

6. Deliver the review to the customer.

This step may not exist in many companies, because their software architecture does not necessarily require customers to review, but the most important thing for a service company like ours is customer respect, implementing the software architecture design activity is to let the customer understand and accept your architecture design scheme. At the same time, the customer will also help you verify the architecture. Generally, our architecture can be developed on a large scale after it is recognized by the customer.

When delivering a review to a customer, the review may usually be conducted in the form of a meeting, so we can refer to the best practices at the review meeting to hold the meeting, so we will not repeat it here.

1

Common Mistakes in Software Architecture Design and Solutions

1. architecture design is often "high to high ". The so-called high to high actually means that our architecture design is only in the model stage, but it is by no means the first regular expression.

2. Architecture Design often overdesigns some aspects (over engineering ). To carry out a series of complex designs for some fundamental changes, such design is called over-design, which often leads to a waste of resources and increases the development workload or difficulty. Although we must consider the scalability and maintainability of the system, we should not over-design it. Sometimes you may not be able to determine which designs are overly-designed. At this time, you can ask your PM to let him stand at the height of the entire project to help you make a decision.

3. architecture is neither a framework nor a combination of several frameworks or technologies. The framework itself is also structured. The framework is generally intended for semi-finished products with good reusability and scalability in one aspect or field. We can use a classic sentence to conclude that the framework is software and the architecture is not software, A framework is a special software. In our work, we can abstract reusable tool classes, public classes, and basic classes to form reusable frameworks.

4. architecture design is by no means a new technology display platform. appropriate technologies are technologies that are beneficial to the project. The capabilities of developers and maintenance personnel must be taken into account. As an architecture designer, we should consider how to balance business needs, organize the relationship between operations (mainly collaboration in teams) and technologies, and not just focus on technical details.

5. The success of architecture design determines the quality of the system. Due to poor architecture design, too many System bugs are delivered and the customer's non-functional requirements cannot be met, this may cause the project to be canceled from time to time. Architecture design is not a task for architects alone, nor a task that can be completed in just a few days. It must be the result of a great deal of hard work by architects, its success or failure is often closely related to the support of organizations, supervisors, and project managers.

Some general skills on Architecture Design

1. layer rules. The layer here refers to the logical layer, not the physical layer ). Currently, most enterprise application systems are divided into three layers: presentation layer, domain layer, and data layer. When dividing different layers, you can consider the following aspects: a. Each layer is a relatively independent part and can be regarded as a whole without having to know about other layers; b. Reduce the dependency between layers to a minimum, that is, reduce coupling. C. You can replace a layer to some extent without affecting other layers. D, layers cannot close everything. If a column is added to the user interface, a data field is added to the domain layer, and a corresponding field is added to the data layer. At the same time, too many layers may have a certain impact on performance.

2. Do not generate circular dependencies between packages. Generally, packages are divided by different logical layers, and under a package layer, they are divided by functions. Avoiding the circular dependency between packages is a common rule. Such a rule must have its own values and principles. The main reason for this is: a. Cyclic dependency will make layers meaningless. B. Cyclic dependency will bring many potential risks. For example, nested transactions may be generated (such transactions are not supported in the javaee standard) I have encountered this problem. In a project, transactions are centrally controlled at the business logic layer. However, because developers ignore this principle in the architecture, the persistence layer calls the public classes of the presentation layer, forming a loop, leading to the occurrence of nested transactions.

3. Application of the design model. In many people's ideas, providing a design pattern is equivalent to a gof design pattern. In fact, a design pattern is a broad concept, for example, the demand mode, domain mode, and anti-pattern all belong to the design mode. Pattern is actually a tool that summarizes people's experience in solving a certain type of problems in the past. Therefore, we can apply various design patterns in design activities, however, before applying these models, you must analyze the problems clearly. Otherwise, you may be confused.

Successful projects have similarities, but failed projects have their own failures. A good software architecture design must be similar to a successful project. Why should we not design the software architecture properly?