Programmer's Architecture Training: Outline of Architecture Design, Business, Application, Technology, and Data Architecture

Architecture design

In the process of architecture design, we will make different architecture designs as needed, and certain core elements of architecture design need to be involved in the design.

Architecture design summary

Architecture design is a transformation from business requirements to system implementation. It is a process of further in-depth analysis of requirements and is used to determine the relationship between entities and entities in the system, as well as the form and function of entities. The architecture can be divided into different needs from business requirements to system implementation: business architecture, application architecture, data architecture, and technical architecture. Let's take the e-commerce system as an example for architecture design.

Business architecture

Business architecture is the refinement and abstraction of business requirements. A set of methodology is used to divide the business boundary of the business involved in the product (project). Simply put, it is to split the business according to a set of logical ideas. The development of software must meet the business requirements. Demand, otherwise it is a castle in the sky. The business complexity of the software system can be solved by dividing the work interface from the perspective of business architecture. For example, when building an e-commerce website, you need to clearly divide the product category, product, order, payment, refund and other functions. Don't consider what technology development, whether the amount of concurrency is too large, and what to choose in the business structure. Kind of hardware, etc.

Here, the business module of the e-commerce system is simply planned, and it is continuously refined according to the business architecture module, and has been decomposed to the code flow. For software development, relying on business architecture, architects and developers can see the full picture of the system's business more clearly, and architects can more easily analyze system complexity, decompose business logic, and do a good job in the division of development, as follows As shown in the figure.

Programmer's Architecture Training: Outline of Architecture Design, Figure 5.1 of Business, Application, Technology, and Data Architecture

Business architecture is the general outline that determines whether a software project can be carried out smoothly. Software architecture is the technical mapping of the business architecture. A reasonable division of labor should also be based on the business architecture. If there is no business structure, software development will be blind. Business architecture is the convergence point of requirements and development. Whether the requirements analysis is in place and whether the function development achieves the expected goals are all based on this. We will encounter some problems in our work. For example, R&D personnel say that the requirements analysis is not in place, while those who do the requirements will question how the requirements are in place and why the products developed are inconsistent with what the users want. Fundamentally speaking, it is because the business structure has not been sorted out clearly and no consensus has been reached.

From the perspective of a software project, doing a good job of business architecture design in the early stage of the project is of great significance to the development of the entire project. For example, for relatively similar business systems, the business architecture may be the same in coarser granularity, but different in the refinement process.

When working on a project, when you have a ready-made system on hand and need to do a project with similar requirements, you may first try to cover the new project with the ready-made system in order to maximize benefits. The realization of this idea can be measured by the business architecture. If there is no business architecture, the next work will be very blind. The design principles of the business architecture are as follows.

(1) Make the business platform.

◎ Business platformization, independent of each other, such as trading platform, logistics platform, payment platform, advertising platform, etc.

◎ The basic business sinks and can be reused, such as users, products, categories, promotions, timeliness, etc. (2) Separate core business from non-core business. Separate the core business of the e-commerce system from non-core business such as main transaction service and general transaction service, streamline core business (conducive to stability), and diversify non-core business.

(3) Isolate different types of business.

◎ The function of the trading platform is to allow buyers and sellers to sign transaction contracts, so it is necessary to ensure high availability first, so that users can quickly place orders.

◎ The performance business does not have too high requirements for availability, but priority should be given to ensuring consistency.

◎ The spike business has high requirements for high concurrency and should be separated from the regular business.

(4) Distinguish between the main process and the auxiliary process. It is necessary to know which are the main processes of the e-commerce system, and give priority to the smooth completion of the main process at runtime; the background asynchronous method can be used for the auxiliary process to avoid the failure of the auxiliary process from affecting the failure of the main process.

Application architecture

Application architecture is between business and technology. It is the overall architecture for the realization of the entire system. It is necessary to point out the level of the system, the principles of system development, and the application services at all levels of the system.

As shown in the figure below, the system is divided into a presentation layer, a business process layer, a service layer, a service construction layer, a data layer, an integration layer, a data architecture layer, and a service governance layer, and the services provided by applications at each level are specified.

When disassembling the system, it is necessary to balance the complexity of business and technology to ensure that the system is not scattered. What kind of application architecture the system adopts is affected by the complexity of the business, including the development stage and business characteristics of the enterprise; at the same time, it is affected by the complexity of the technology, including the development stage of IT technology and the level of internal technical personnel. The complexity of the business (including the large business volume) will inevitably bring about the complexity of the technology. The goal of the application architecture is to solve the complexity of the business while avoiding the complexity of the technology and ensuring the implementation of the business architecture.

Programmer's Architecture Training: Outline of Architecture Design, Figure 5.2 of Business, Application, Technology, and Data Architecture

The design principles of the application architecture are as follows.

(1) Stable

◎ Everything is centered on stability.

◎ The structure is as simple and clear as possible, pursuing small and beautiful, not big and comprehensive.

◎ Not excessively designed.

(2) Decoupling

◎ Separate the stable part from the variable part.

◎ Separate core business from non-core business.

◎ Separate the main e-commerce process from the auxiliary process.

◎ Separate application and data.

◎ Separate service and implementation details. (3) Abstract

◎ Application abstraction: The application only depends on the service abstraction, and does not depend on the details and location of the service implementation.

◎ Database abstraction: The application only depends on the logical database and does not need to care about the location and sharding of the physical database.

◎ Service abstraction: application virtualization deployment, no need to care about the configuration of the physical machine, dynamic allocation of resources.

If you feel that your learning efficiency is low and you lack correct guidance, you can join a technical circle with rich resources and a strong learning atmosphere to learn and communicate together!
[Java Architecture Group]
There are many first-line technical experts in the group, as well as code farmers who are struggling in small factories or outsourcing companies. We are committed to creating an equal and high-quality JAVA communication circle. It may not be possible to let everyone in the short term. Technology advances by leaps and bounds, but in the long run, vision, pattern, and long-term development direction are the most important.

(4) Loosely coupled

◎ Asynchronization of cross-domain calls: try to asynchronously decouple between different business domains.

◎ Try to be asynchronous for non-core business: Try to be asynchronous between core business and non-core business.

◎ When it is necessary to call synchronously, it is necessary to set the timeout period and the length of the task queue.

(5) Fault-tolerant design

◎ Service autonomy: Services can be modified, deployed, released and managed independently of each other to avoid chain reactions.

◎ Cluster fault tolerance: Application system cluster deployment to avoid single point of service.

◎ Multi-computer room disaster recovery: Multi-computer room deployment and more activity.

Technology Architecture

Technical architecture is the implementation of technical solutions for the functions (or services) proposed in the business architecture, including software system implementation, operating system selection, and runtime design. The boundaries of the technical architecture are relatively fuzzy. For different audiences, the level of detail of the content is also different. The technology stack pays more attention to the technical architecture from top to bottom, but the points of attention at each layer are different. The technical decision-making level may be concerned about the technical selection of the system or system group. The overall grasp of the selection must ensure that other risks are not caused by the selection. For example, if you choose Redis for high-performance storage, you must try to ensure the closedness of the network. Avoid public network access; for example, when choosing various products implemented in COBOL language, consider the small number of developers in the market and the need to bear higher iteration costs.

A simple technical architecture of the above business architecture is shown in the figure below.

Programmer's Architecture Training: Outline of Architecture Design, Business, Application, Technology, and Data Architecture Figure 5.3

The design principles of the technical architecture are as follows.

(1) Stateless, that is, try not to save the state data on the machine.

(2) Reusable.

◎ The granularity of reuse is an abstract service with business logic, not the implementation details of the service.

◎ Service reference only depends on service abstraction.

(3) Loose coupling

◎ Cross-business domain call, asynchronous decoupling as much as possible. ◎ Set the timeout time and queue size when calling synchronously.

◎ Separate relatively stable basic services from volatile process services.

(4) Governable

◎ Service can be downgraded.

◎ Service can be limited.

◎ The service can be switched on and off.

◎ Service can be monitored.

◎ Whitelist mechanism.

◎ Develop a service contract.

(5) Basic services

◎ Basic services are sinking and reusable, such as timeliness, inventory and price calculation.

◎ Basic services are autonomous and relatively independent.

◎ The realization of basic services should be streamlined and can be expanded horizontally.

◎ The realization of basic services must be physically isolated, including data related to basic services.

Data architecture

Data architecture is the architecture for storing data (resources), its design principles and application architecture

The design is similar, the business scenarios of the system need to be considered when designing, and the data needs to be heterogeneous design, database read and write separation, distributed data storage strategy, etc. according to different business scenarios. Figure 5.4 shows an overview of the data structure in the e-commerce system.

Programmer's Architecture Training: Outline of Architecture Design, Business, Application, Technology, and Data Architecture Figure 5.4

The data structure consists of two parts: the content of the static part and the content of the dynamic part.

The content of the static part focuses on the data element model, data model, including the analysis and modeling of master data, shared dynamic data and all business-related business object data; the focus of the dynamic part is the management and control of the full life cycle of the data And governance. Therefore, the data architecture cannot be simply understood as a purely static data model. The analysis focus of the data model in the business architecture is the main data and core business objects, and the analysis focus of the data model in the application architecture is further transformed into a logical model and a physical model, until the final data storage and distribution.

Data has two levels of life cycle: the full life cycle of single business object data, which is often related to a single workflow or approval flow in process modeling; the full life cycle of object data across multiple business domains, it reflects Conversion and mapping between multiple business object data,

It is often related to the end-to-end business process BPM. It should be noted here that although data is a static level content, the life cycle of the data or end-to-end data mapping often indirectly reflects the process, which is a very important content.

Data modeling methods include structure-oriented traditional ER model analysis methods, as well as object-oriented object class model analysis methods. They are all feasible data modeling methods, but traditional ER model analysis methods are easier to implement to the underlying physical database model The conversion of object-oriented object class modeling method is easier to reflect abstraction and reuse. Especially in enterprise architecture modeling, object-oriented and structure-oriented are often not strictly distinguished. In many cases, the two methods will be mixed, but the focus is to distinguish the focus of each method or tool and the problem to be solved. There are quite a lot of data-related matrix analysis. The key matrix analysis in the business architecture phase is the CRUD-like matrix analysis between business objects and business processes, business components, and business functions; while the key matrix analysis in the application architecture phase is the logical or physical model object and Matrix analysis between specific application modules or application functions. The thinking of the two is basically similar, but the level of attention is different. The former focuses on the identification of master data and the analysis of business components, while the latter focuses on the division of application function modules and the preliminary analysis of the integrated interfaces between modules.

According to the previous ideas, we should still decompose data integration analysis into two levels: analysis at the business level, and analysis at the application and IT implementation level. The focus of the former is to clarify the integration and interaction of business objects between business processes or business domains, while the focus of the latter is how to better share data or how to achieve data integration and interaction through similar BI tools or big data platforms.

The design principles of the data architecture are as follows.

(1) Unified data view, that is, to ensure the timeliness, consistency, accuracy and completeness of data.

(2) Data and application are separated.

◎ The application system only relies on the logical database.

◎ The application system does not directly access the database of other applications, only through the interface.

(3) Data heterogeneity, that is, index heterogeneity when the content of the source data and target data are the same, and database heterogeneity when the content of different dimensions of the product library is different (such as the buyer database and seller database in the order data).

(4) Separation of database read and write.

◎ Separate reads and writes from databases with a large amount of visits, such as an order database.

◎ Sub-database and sub-table for databases with a large amount of data.

◎ Partition the databases of different business domains. ◎ Configure backup database for important data.

(5) Use relational database. In addition to cost factors, MySQL has strong database scalability and high concurrency support capabilities, and it is easier to recruit relevant R&D personnel and operation and maintenance personnel.

(6) Reasonable use of NoSQL databases. When the database is capable of supporting it, try not to introduce caching. In addition, it is necessary to make reasonable use of cache for disaster recovery.

Write at the end

I recently compiled a complete set of "Summary of JAVA Core Knowledge Points". To be honest, as a Java programmer, whether you need an interview or not, you should take a good look at this information. There is no loss if you get your hands~ Many of my fans have also gotten Tencent Byte Kuaishou offer, click on the picture below ↓ to receive it directly , the above is the whole content of this article, if you feel that you have gained, remember Sanlian, we See you next time.