Software Architecture

The purpose of software architecture design

    For outsourcing business type projects, the purpose of software architecture design is different from that of product type projects. The purpose of software architecture design for outsourcing type projects is mainly discussed here.

    1. Provide the basis and specifications for large-scale development and provide reusable assets. The large-scale development of software systems must have a certain foundation and follow certain specifications, which is not only a requirement of software engineering itself, but also a requirement of customers. In the process of architecture design, some common parts can be abstracted to form public classes and tool classes to achieve the purpose of reuse.

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

    3. Reduce the cost of development and maintenance, a large number of reuse and abstraction, can extract some common parts that developers do not care about, so that developers can only focus on the implementation of business logic, thus reducing a lot of workload and improving development efficiency.

    4. Improve the quality of products. Good software architecture design is the guarantee of product quality, especially to meet the non-functional requirements often put forward by customers.

    Principles of

    software architecture design Software architecture design must follow the following principles:

    1. Satisfy functional and non-functional requirements. This is the most basic requirement of a software system, and it is also the most basic principle that should be followed when designing the architecture.

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

    3. Meet the requirements of reuse and maximize the work efficiency of developers.

    Several Views of Software Architecture Design

    We often ask various questions when discussing what to do in architecture design, or in architecture design review meetings, such as how should developers record logs and how should transactions be controlled? How can we improve the productivity of our developers, that is, to complete more functions with higher quality in unit time? How to meet customer's non-functional requirements? How to make the platform managers of the production environment better maintain the system?

    The above questions are actually questions raised by different stakeholders of the software system from different perspectives. To answer these questions, we have to look at the work of software architecture design from different perspectives.

    1. From the perspective of logical architecture, consider the problem from the perspective of system users. The designed software architecture can meet the needs of business logic, and can handle more and more complex business logic requirements.

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

    3. From the perspective of operation architecture, consider the quality requirements of the system during operation, and pay special attention to the non-functional requirements of the system. Customers often require that the longest response time of the functional screen of our system does not exceed 4 seconds, which can satisfy 2,000 users at the same time. Online usage, role-based security control of system resources, etc.

    4. From the perspective of physical architecture, pay attention to the environment in which the system is installed and deployed, such as the most popular enterprise application service solutions IBM Http Server + WebSphere Application Server + DB2, WebLogic + Oracle, etc.

    5. From the perspective of data architecture, the various systems we develop today, such as MIS, ERP, and SAP, basically operate on various types of data, and display a bunch of data that is not easy to understand into data that users can easily understand. Automatic processing of various data operations, etc., so the persistence of data is a very important thing.

1. Analyze requirements and understand business model (or domain modeling), and select key use cases.

    Software requirements can be divided into users' perspectives and developers' perspectives. From the user's perspective, they can be divided into functional and non-functional requirements. We must comprehensively understand and analyze requirements from different perspectives and levels. requirements, understand the business model. Practice has shown that non-functional requirements that are often overlooked by us often lead to the failure of the entire project.

    The best way to understand business requirements is to conduct domain modeling. Domain modeling and demand analysis are often alternately carried out. Domain modeling has the following three functions:

    ◆Explore complex problems and clarify domain knowledge. Martin Fowler once said that the biggest benefit of his object-oriented approach is that it helps solve more complex problems. Domain modeling itself, as an auxiliary thinking tool, helps us to keep our attention on the most important business concepts and their relationships, and enables us to analyze and understand requirements in a deep and systematic manner. Domain modeling is often a process from vague to clear, from fragmented to systematic.

    ◆Determine functional scope and affect scalability. Any model is an abstraction of a certain program in the real world, and this abstraction will ignore certain things, such as ignoring the attributes of objects and the relationship between objects, and these ignorances are often purposeful. Ignoring it determines the scope of the function. The model reveals the structure behind various functions. If defining a function is equivalent to "taking a picture", then domain modeling is equivalent to "perspective", paying more attention to the internal structure of the problem domain, which is equivalent to making a certain amount of the problem domain. Abstract, a good domain model can not only support existing functions well, but also support new requirements that may appear in the future to a certain extent, reflecting good scalability.

    ◆Provide a foundation for communication and promote effective communication. Domain modeling usually uses UML diagrams as a way of presentation, which facilitates 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, this link is often missing from domain modeling, which may be an area that needs to be further improved in future work.

    Although we always expect architects to have a comprehensive grasp of requirements, due to time and energy constraints, the reality in front of us is that architects do not have time to conduct in-depth analysis of all requirements, so our strategy is "use good steel for On the cutting edge”, i.e. spend most of your time and energy on the critical requirements that are most important in determining the architecture. Be careful when selecting critical requirements: high-priority requirements tend to be viewed from the user's perspective and may not really be critical requirements. In the book "RUP Practitioner's Guide" tells us how to identify key functional requirements? A. As the core of the application or the functions that implement the main interface of the system, B. The functions that must be implemented, that is, if these functions are not implemented, the developed software will lose its value, C. Cover the system architecture Some aspects, but not functionality covered by other important Use cases.

    2. Consider all aspects of software architecture from various perspectives.

    The architectural design of the software must consider all aspects, and design according to the domain model established in the previous work, key requirements, system constraints, etc., and must be designed from the perspectives of system users, developers, system administrators, deployment administrators, data administrators, etc. to analyze and solve problems. For example, if our operating architecture adopts the Cluster mode, we must be careful about the use of Cache and Session; if our business logic requires us to operate multiple databases, we must consider adopting a method that supports two-phase transaction submission.

    Only when these aspects are taken into account, such an architectural design is complete. As for what details we should design in each view, it is actually related to the process definition of the entire project. For example, if we have an activity dedicated to arranging database outline design, then we can only focus on higher-level database features and relationships between databases in the process of schema design, and the data dictionary of each table can be used in subsequent related activities, but if there is no such activity, then we have to refine each field of each table and the relationship between the tables.

    3. Solve key technical problems and problems

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

    When encountering a really difficult problem, you can go to Baidu or Google, or you can ask the company's senior technicians or experts, or hold a small-scale technical discussion meeting, and use the method of brainstorming to try to find the answer , so as to improve work efficiency.

    4. Hold an architecture design review meeting for peer review.

    Architecture design review is an extremely important part. I once described it as the parting hook in the "seven weapons", because at the meeting, colleagues may raise many questions or opinions, and many opinions are very sharp, so it must be It is necessary to accept it with an open mind and keep a record of it, as the so-called "good medicine is bitter and good for the disease, and honest words are good for deeds".

    Before the review meeting, we have to do a lot of preparation work, it is best to prepare a concise electronic briefing, list the most important issues, so that when the review meeting is conducted, it will not be aimless, before the meeting. Just send these materials to the participants, and ask them to take the time to understand first. During the meeting, they must learn 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.

    The verification of the architecture design is also a very important work. There are many verification techniques. In our company, we usually use the form of Sample, that is, iteration 0 in XP and slice in RUP. The advantage of this is that it can effectively verify whether the architecture meets the requirements from the perspective of the actual product, and it can save costs compared with the throwaway prototype verification technology.

    This Sample is by no means a piece of code that we use for experiments when solving problems in architecture design, but a complete implementation of a key Use case that conforms to the architecture design and a series of specifications. Deliverable code and related documents. At the same time, this sample can be used as a teaching material when you explain or train the architecture, and it can also be used as a blueprint for developers to use this architecture for development, or even just copy and paste, and add simple modifications.

    6. Deliver to customers for review.

    This link may not exist in many companies, because their software architecture does not necessarily require customer review, but for companies like us, the most important thing is customer respect, which is implemented into the software architecture design activity. It is to let customers understand and accept your architectural design, and at the same time, customers will also play a role in helping you verify the architecture. Typically, once our architecture is approved by our customers, we can move on to large-scale development.

    When the review is delivered to the customer, the review may usually be carried out in the form of a meeting, so we can hold a meeting with reference to the good practice of the review meeting, which will not be repeated here.

Common misunderstandings and solutions in software architecture

    design The so-called high ups and downs actually means that our architecture design only stays in the model stage, but it is by no means the first sample program.

    2. The architecture is often over-engineered in some aspects. Carrying out a series of complex designs for some changes that will not happen at all is called over-design, which often leads to waste of resources and increases the workload or difficulty of development. Although we must take into account the scalability, maintainability, etc. of the system, we must not over-design. Sometimes you may not be able to judge which designs are over-designed. At this time, you can ask your PM to help you decide from the height of the whole project.

    3. Architecture is not a framework, nor is it a simple combination of several frameworks or technologies. The framework itself also has a framework. A framework is generally a semi-finished product with very good reusability and scalability for a certain aspect or field. We can summarize it with a classic sentence: a framework is software, an architecture is not software, and a framework is a special kind of software. In our work, we can form some reusable frameworks by abstracting many reusable tool classes, public classes, basic classes, etc.

    4. Architecture design is by no means a new technology display platform. Appropriate technology is the technology that is beneficial to the project. It must take into account the capabilities of developers and maintainers. As an architect, you should think more about how to balance business requirements, weaving operations (mainly referring to collaboration in the team) and technology, rather than just paying attention to those technical details.

    5. The success of the architecture design determines the quality of the system. Due to the poor architecture design, there are too many bugs in the delivered system, which cannot meet the non-functional requirements of customers, etc., which lead to the case of project cancellation from time to time. Architecture design is not the work of the architect alone, nor is it a job that can be completed in a few days. It must be the result of a lot of hard work by the architect, and its success or failure is often closely related to the support of the organization, supervisor, and project manager. Relationship.

    A little general skill about architecture design

    1. Layer rules. The layer here refers to the logical layer (Layer), not the physical layer (Tier). Most of the current enterprise-level application systems are divided into three layers, namely the presentation layer, the domain layer and the data layer. When dividing each level, it can be mainly considered from the following aspects: A. Each level is a relatively independent part, which can be regarded as a whole without knowing about other levels; B. Reduce the dependency between levels To the lowest, that is to reduce the coupling; C. A layer can be replaced to some extent, without having too much impact on other layers; D, the layer can not close everything, if the user interface adds a field, then the domain layer will add a data field, and the data layer will add a corresponding field. At the same time, too many layers may have a certain impact on performance.

    2. Do not generate circular dependencies between packages. Usually the division of the package will be divided according to different logical layers, and then divided according to the function under the package of the layer. Avoiding circular dependencies between packages is a relatively general rule. Such rules must have their value and reason. The reason for this is mainly for the following reasons: A. Circular dependencies will make layering meaningless; B. Circular dependencies will It brings many potential risks, such as the phenomenon of nested transactions (nested transactions, which are not supported in the JavaEE standard). I have encountered such a problem. In a project, transactions are placed in the business The logic layer is controlled in a unified manner, but because developers ignore such principles in the architecture, the public classes of the presentation layer are called in the persistence layer, forming a loop phenomenon, which leads to the occurrence of nested transactions.

    3, the application of design patterns. In the opinion of many people, providing design patterns is equivalent to the design patterns of GOF. In fact, design patterns are a broad concept, such as requirement patterns, domain patterns, and anti-patterns, which are all design patterns. A pattern is actually a tool, a summary of people's experience in solving a certain type of problem in the past, so we can apply various design patterns in design activities, but we must first analyze the problem before applying these patterns, otherwise it may appear The phenomenon of "the bull's head is not the horse's mouth".

    Successful projects have similarities, and every failed project has its own failures. A good software architecture design must be the similarity of a successful project. What reason do we have for not doing a good software architecture design?