Shulou(Shulou.com)06/02 Report--

overview

First, what is the system? According to the definition of System Architecture, a system is a collection of entities and relationships between them, whose functions are greater than the sum of their respective functions. For our scenario, the system could be an App, Web app, service, batch program, etc., or it could be a large system that includes all of them.

As the Internet and traditional enterprises become more and more integrated, business will become more and more complex. How do we design our systems?

From product to R & D

There is a huge gap between prototyping and programming. The more complex the business requirements, the greater the gap. In general, we have at least two more steps: business analysis and architectural design.

Business analysis, mainly dealing with business domain modeling. The problem solved is how to achieve it in business. Then there is the design of technology and architecture, mainly aimed at technical implementation, and the problem solved is how to achieve it technically. These two aspects will affect each other, and design often needs to consider these two aspects back and forth. Even system development often requires adjustments to the model or architecture, and of course updates to documentation accordingly.

basic principles

The process of design and analysis is constantly abstracting and encapsulating, and determining the details of each system entity. Abstraction refers to abstracting the business into elements (systems, modules, or classes) of the software domain; encapsulation refers to defining the boundaries of elements, hiding implementations, and opening interfaces.

Accordingly, abstraction and encapsulation are fundamental principles of analysis and design. Of course, we have SOLID, DRY, high cohesion and low coupling, design patterns and other principles and methods, the specific methods will not be detailed in this article, but ultimately they can be classified into the above two points.

business analysis

analysis method

Business analytics are modeling for business domains, and outputs are analytical models. The analysis model describes the logical design and structure of the system, generally including requirements use cases, entity models, and interaction processes and state transitions of business scenarios. Analytical models allow non-technical people to understand how systems are constructed and technical people to build systems based on them.

The process of analysis is iterative. Especially for complex requirements involving multiple business areas, the first step often requires analysis at the overall system level, then dividing the model into multiple subsystems, and then performing more detailed analysis and modeling at the subsystem level.

On the other hand, the analysis process requires constant optimization and adjustment. For example, when determining the behavior details of the entity, it is found that the coupling between the two entities is very high, so it may be necessary to re-abstract and adjust the functional scope of the entity.

Clarify business requirements

Clarifying business requirements is a prerequisite for all analysis and design:

Identify stakeholders and their concerns.

Determine the business requirements of the system, i.e. who uses the system and what it does.

Determine the functional scope of the system, i.e. what the system "contains" and what it does not contain.

The system needs to satisfy stakeholder concerns, so make sure all of these concerns are addressed. The most important stakeholders are of course users (sometimes subdivided into different types of users), but also suppliers, partners, operations, sales, bosses and even governments, as well as R & D testing and operations.

Specific to the users of the system, you also need to subdivide into roles, even though some roles may actually be the same person. For example, for outpatient clinics, there may be nurses, consultants or system administrators, etc., who can perform different operations. A simple list of requirements can be used, and complex systems can be considered using use case diagrams.

For example, a use case diagram for an outpatient appointment system could be drawn as follows:

The roles are doctor, patient and outpatient staff.

Use cases include scheduling, managing appointments, and booking/canceling doctors.

Build a solid model

A solid model is the process of determining the entities contained in a system and the associations between them:

Clarify business concepts and unify business vocabulary.

Abstract business entities, including events, people/roles, places, and things.

Identify entity relationships: inheritance, aggregation, association, etc.

Entity models are also called ER (Entity-Relation) models. You can consider using four-color modeling, which can generally be represented by class diagrams or component diagrams. It is important to clarify the concept of business, unify the naming and definition of business-related vocabulary, which is the basis for further communication.

For example, an entity diagram for a reservation system could be drawn as follows:

Analyze business scenarios

Scenario analysis is used to determine the interaction process of each participant in a specific business scenario to further improve the analysis model:

Analyze specific business scenarios, determine business rules, and sort out business processes.

If complex state transitions are involved, state transition logic needs to be determined.

Complement and perfect the content description of entity model.

For a business scenario, participants may include people, internal modules, external services, etc. This step requires a clear understanding of the entire business process and rules. It should be noted that for some minor paths or abnormal paths, it must also be considered. For business processes and rules, you can use common flowcharts, swim lanes, or UML activity diagrams, and state transition processes can be represented by UML state diagrams.

For uncertain requirements in scenario analysis, or where there may be technical difficulties, you can record them and confirm and verify them later.

For example, the following is a reservation state diagram of the reservation system.

For example, below is a flowchart of our interaction with a pharmaceutical supplier.

Architecture and Technical Design

architectural approach

Architecture design does not have to go into specific implementation details, but should consider all aspects of the system as comprehensively as possible. The key is to have a greater grasp of project risks, so as to avoid uncontrollable problems in the development process. The specific design needs to be more detailed, which requires the designer to grasp the degree himself.

For content that cannot be determined for the time being, it should be noted in the documentation that testing and verification are performed early in the development process. If it is critical to the project, consider developing a prototype first to validate it.

Architectural design is commonly seen in 4+1 views, i.e. logical view, development view, process view, physical view, plus scenario. Another approach I prefer is the viewpoint and perspective approach, which is probably more comprehensive if you add scenes.

Determine the overall structure

First of all, we need to consider the location and responsibilities of the system as a whole:

Determine the system's position in the overall context, its association with other systems.

Determine the responsibilities of the system itself and of each external system.

The overall architecture corresponds to the situational view. This step treats the system as a black box, identifying the scope and responsibilities of the system itself, the responsibilities of related external systems, and the relationships between them.

For example, the overall architecture of a trading system looks something like this:

Design function module

Secondly, it is necessary to determine the functional modules within the system and their responsibilities:

Determine the modular division of the system.

Determine the responsibilities of each module and the relationships between modules.

Function modules correspond to function views. This step requires clarifying the internal structure of the system. Internal module division is mainly based on business function division, and division based on implementation hierarchy, slightly more complex systems may have both. There are also some systems that adopt CQRS architecture, so the module division may be different. Functional modules can be represented using UML component diagrams.

Clarify architectural concerns

Then you need to define the concept of the system architecture:

Clarify architectural design concerns.

Identify architectural design trade-offs for the system.

This step requires consideration of various architectural perspectives, including (but not limited to) the following concerns:

Security: authentication, rights control and authorization, logging of operations, security auditing, data consistency, etc.

Performance: Response time, throughput, etc.

Stability: downtime, failover, data consistency, data backup, etc.

Scalability: Possible future changes and how to respond to them.

Others: Internationalization, ease of use, compliance, etc.

All the above concerns, resources, time and scope of development are often difficult to meet at the same time, so it is necessary to clarify which are the key points of concern and which can be compromised. For example, data consistency may need to be reduced to meet performance requirements, and more development time may have to be spent for compliance.

Possible future changes must also be considered. Usually, we have to consider at least the architecture for the next six months, but may only implement the version currently needed, but make sure it can be easily extended in the future.

Once the focus has been identified, we need to keep that focus in mind throughout every process of design and development.

For example, for an order system, consistency and traceability of data is extremely important because money and transactions are involved. API for orders and payments must be idempotent, every revenue movement must be logged, and there must be strict checks and reconciliations. For security, every API call must be authenticated.

Amazon, for example, has a well-known principle that all intersystem calls must go through well-defined APIs and that sharing databases is not allowed. This is also a structural principle.

Design database model

If you have a solid model for your analysis, designing a database model is not difficult. After development is complete, the database model should be based on the database, and the schema document does not need to retain this part.

Note that a database model is an implementation of the entity model in a relational database, but not necessarily a strict mapping. The database may have normal form, redundancy, consistency, synchronization, sub-table sub-database considerations, if necessary, may use non-relational databases such as ElasticSearch, Cassandra, etc.

Sometimes it involves data processing. For example, an image may need to be preprocessed after submission, then reviewed and marked by operations personnel, and finally published. The storage form or status tag of the data in the process may be different.

More specifications for database design can be found in Database Specifications.

design interface

Then you need to determine the API details. In general, the API of our service is requests and callbacks in HTTP form in JSON format. API may be an interface definition, or there may be other interface forms, such as message queues. During the design phase, API documentation can be recorded through Markdown documentation, RAP, etc., and can be maintained independently after development, or maintained together with code using Swagger.

Interface design needs to pay attention to several points:

The design of the interface should be based on the domain resources or services provided by the system, taking into account the requirements of the caller.

The granularity of the interface is very important. Too detailed is inconvenient for the caller to call many times. Too coarse is unable to flexibly meet various requirements. It needs to be carefully weighed.

The design of the interface also needs to consider how the call is made from the caller's perspective. If necessary, you can draw a flowchart, timing diagram, state diagram detailing the call sequence, that is, state transitions, etc.

The documentation of the interface must clearly describe the method of calling the interface, preconditions, parameters, processing of different conditions, return interface, etc.

Scene realization

In general, with business scenario analysis, database model and API, the implementation of the system is generally relatively simple. However, there may be some details that need to be further considered for implementation details to avoid risks. More detailed activity diagrams, timing diagrams, and even pseudocode can be considered. For example:

Detailed design of complex business scenarios or implementation description of complex algorithms.

How, when, and how offline tasks are performed.

Non-business scenarios, such as network disconnection, cache failure, third-party system downtime, etc.

For example, for the WeChat Web payment process of the payment system, there are many systems involved and the interaction is complex, which can be clearly defined by the time sequence diagram:

other considerations

For our back-office systems, the basic technical framework has been established to address many of the underlying non-business requirements. However, when designing the system, you still need to consider the following aspects:

Common handling methods, such as logging, error handling, code specification, unit testing, etc.

Data migration, synchronization, and rollback scenarios: Refactoring legacy systems requires careful consideration and rehearsal.

System deployment and release: If the system involves multiple subsystems, consider the deployment architecture of the system. Especially when data migration is involved, be sure to carefully consider the release process.

System Monitoring and Alarms: Are there any special indicators that need to be monitored in addition to regular monitoring and alarms?

Concurrency and data volume: If the system is likely to face problems with high concurrency and large data volumes, design a corresponding solution, as well as related performance and stress tests.

Cache design: If you need to use cache, in addition to considering the selection and scheme of cache, you should put cache into the whole system for design.

Technology selection: When it comes to the introduction of new technologies, it is necessary to carefully analyze the advantages and disadvantages of alternative technologies and select the most appropriate solution.

design methods and tools

UML

Object Oriented Design (OOAP)

Domain Driven Design (DDD)

CQRS & Event Sourcing

reference books

Analysis pattern: reusable object model (https://book.douban.com/subject/4832380/)

Software Systems Architecture: Working with Stakeholders Using Perspectives and Perspectives (https://book.douban.com/subject/24530471/)

UML and pattern applications (https://book.douban.com/subject/1792387/)

Architecture is the Future: Scalable Web Architecture, Processes, and Organization for the Modern Enterprise (https://book.douban.com/subject/26765979/)

article

From use case analysis to solution review, how we approach business systems design (http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg)

Internet company RD How to write general design and detailed design documents (http://www.10tiao.com/html/249/201412/201657741/1.html)

System Analysis with UML (http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis)

Domain analysis using four-color modeling (http://www.infoq.com/cn/articles/xh-four-color-modeling)

From "Four-color Modeling Method" to "Boundary Paper-and-Pen Modeling Method"(http://insights.thoughtworkers.org/paper-pen-modeling/)

My Understanding of DDD Domain Driven Design (http://www.cnblogs.com/netfocus/p/5548025.html)

Domain Driven Design Reference Architecture (http://blog.csdn.net/bluishglc/article/details/6681253)

Domain-driven design and practice (http://www.infoq.com/cn/articles/cjq-ddd)

My thoughts on CQRS/EventSourcing architecture (http://mp.weixin.qq.com/s?__ biz=MzA5Nzc4OTA1Mw==&mid=2659598125&idx=1&sn=ca39d804aede5ee46988b6d635217027 )

Architecture Design Basics Collation (https://blog.dreamtobe.cn/2016/03/09/oo_architecture/)

Author: Zhang Yeming, almond doctor CTO. Middle-aged programmer, focusing on various technologies and team management.

Source: https://mp.weixin.qq.com/s/JoKzg2vUe2IwX099xSFtFA

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.