How does the business team unify the architectural design style?

Introduction to first online application. Have you ever felt that you have no idea how to build a business framework? Maintaining online applications, are you in the quagmire when facing a lot of historical baggage? Why are the design styles of different people so different for the same business application? Why is the original design always completely different after multiple iterations? How can newcomers come to the team to quickly understand the business without being tortured by a lot of technical details? If you also have these problems, I hope this article can provide some help.

Author | Mu Shen
Source | Alibaba Technical Official Account

When the application was launched for the first time, did you ever feel unable to start when faced with the establishment of a business framework? Maintaining online applications, are you in the quagmire when facing a lot of historical baggage? Why are the design styles of different people so different for the same business application? Why is the original design always completely different after multiple iterations? How can newcomers come to the team to quickly understand the business without being tortured by a lot of technical details? If you also have these problems, I hope this article can provide some help.

Original intention

1 Fragmented architecture in detail

There are many mature application frameworks in the industry. Whether it is SpringMVC/SpringBoot or SofaBoot, they have given clear specifications for the engineering structure, and the boundaries of responsibilities seem to be very clear. But in practice, no matter how simple a business application is, the business logic is scattered everywhere, breaking the module boundary and the phenomenon of implicit coupling appears. The scattered business details will inevitably lead to the fragmentation of the application architecture. If there is no continuous reconstruction and adjustment, it will eventually become complicated and bloated (of course, under the premise of continuous new demands). Redo 2.0. Investigating the reasons, I personally think that the main reasons are:

• Framework flexibility is too high: The application framework gives engineering specifications, not business design specifications, which retains great flexibility for developers. A business function can be implemented in many ways.
• Insufficient architectural constraints: The establishment and maintenance of the business architecture are the result of different people's inputs at different times. Different design thinking, different self-requirements, and different project schedule pressures will all have an impact on the current status of the application.

If the relationship between law and ethics is used as an analogy, the general framework constrains the “legal” bottom line of technical coding, and the design principle is the developer’s own “ethical” requirements. In a simple business scenario, meeting needs is the first priority, and the demand for design capabilities is not prominent. However, under a multi-party collaborative business team (which is mostly the case), without a unified "ethical standard", it will be difficult to form a joint effort to complete a complex project. The "Java Development Manual" (Alibaba Java Development Protocol) has taken a big step on the road to advancing coding standards, greatly improving the professional quality of engineers and greatly improving the "ethical consensus." So in the field of business architecture design, is it possible to establish a set of "design specifications" for business R&D students at least within a certain problem domain.

2 Technology precipitation loss

On the other hand, after entering Alibaba, although his own R&D experience is not much, he has been exposed to many excellent designs. These outputs, regardless of whether they are the best solution or not, reflect the good wishes of technical students for excellent design and strong landing ability, and they have indeed effectively ensured business development in a certain historical period. However, what puzzles me is that although every business project and business product can precipitate some reusable components or frameworks, the students participating in the research and development can also summarize a set of design principles and practical experience for future needs, but These wealth are always difficult to maintain and pass on. The possible reasons are (I don’t know much about the front-end/test/data/platform research and development experience, here is only for the first-line business research and development):

• Adhere to design results rather than design principles: R&D students with successful experience tend to use previous architecture designs to apply current business scenarios. There is no right or wrong of this kind of thinking, but if the nail is not equipped with a hammer, it will often introduce a lot of additional costs in a short period of time, but lose the original design advantage. In the face of specific problem domains, only by adhering to consistent design principles and dynamically weighing many factors in the process of demand analysis can we create a design that truly meets current and future needs.
• I like to build new wheels instead of continuous refactoring: The design principles and code cleanliness of R&D students may be a kind of "metaphysics". Not waiting for the code of predecessors is a more deterministic normal. In fact, this is not difficult to understand. Even if they are all DDD genres, they may not recognize each other when communicating; even if the architecture design is agreed upon after concessions, the style of coding implementation is also the best. Is it more important to understand the design ideas and code habits of the predecessors, or to complete the business requirements on time? Is it easier to rewrite according to the design style you are good at, or to continuously refactor and optimize on the "outdated" design of others?
• Rely on document inheritance rather than tool reuse: For newcomers, no amount of suggestions and quick start guides in the document can compare to an out-of-the-box engineering DEMO; those who continue to develop on mature applications will not Because the capitalized precautions in historical documents resist the temptation of temporary code in exchange for getting off work earlier, unless there are compulsory constraints in the application engineering that compile/deploy failures make you have to give up.

Compared with the inefficient collaboration caused by the lack of a "design protocol", it is even more regrettable that the "prototype of protocol" that has been deposited is easily abandoned. The daily work of business research and development is essentially to dismantle the complexity of the problem domain, and use multiple ideas of layered decoupling/tooling/platformization/business abstraction to break down the sub-problems one by one. If some of the sub-problems have been solved well, why not stand on the shoulders of the predecessors? Give up the entangled mentality of not making new "wheels", perhaps we need to build the mentality of "building blocks" even more.

Two ideas: business architecture design protocol

Combining the technical practice of the AntChain-application technology team in recent years, we tried to start from our own needs and build a set of business architecture design specifications that might be able to meet more business scenarios. It is important to note that this article proposes a solution from a limited problem domain, and does not seek to become a general solution. If other business lines have similar pain points, I hope they can learn a little bit.

• Standards: unified business design framework, simplified technical details with standardized framework
• Precipitation: Continue to precipitate "building blocks" from business scenarios
• Refactoring: Continuously refactoring "building blocks" to reduce redundant construction
• Integration: rapid integration based on business service orchestration engine

1 Standard-reduce details

Ideally, business technology only needs to focus on domain modeling, but in reality it has to consider more general technical details. Taking the simplified version of the accounts receivable issuance process in the supply chain finance scenario as an example, the following things need to be considered:

• Domain Modeling: Design of the Domain Model and Behavior of Accounts Receivable
• Process orchestration: design of process model and state machine design of issuance process
• Data conversion: two-way conversion of domain model <-> data model and process model <-> data model
• Concurrency control: the design of business lock mechanism
• Business idempotence: idempotent control of each business link in the process
• Exception handling: exception capture, error code convention
• Monitoring alarm: summary log, exception log, boundary log
• other

Among the items not fully enumerated above, except for "domain modeling", they are basically irrelevant to the specific business, but are indispensable for a stable and reliable business application. If a standardized framework scheme can be established, and a large number of details that are irrelevant to the business can be solved with a unified specification, will it be possible for business technology students to truly focus on "domain modeling"?

2 Precipitation-Ability Reuse

Precipitation and reuse are the most common words in the technology group, which shows the high degree of recognition. Capability reuse is not limited to form and granularity. It can effectively reduce technical costs and improve business scalability. It is a good precipitation and can be used as a "building block" for subsequent use. Take the scenario of the AntChain application technology team as an example. The capabilities that have accumulated in recent years include but are not limited to:

Technical

• Engineering specification series: Constraint coding specification and boundary interface definition style, log printing, exception handling, storage behavior, state machine, etc.
• Read and write separation mechanism: shield the design conflicts between transaction and query requirements on the data model, reduce design complexity, and improve query performance and flexibility

Business Class

• Online banking core: improve the scalability of online banking core signatures in different business processes
• Contract on-chain: Improve the scalability of smart contract docking in different business processes

Platform Class

• Configuration Center: Flexible definition and management of various configuration items required by business processes
• Product Center: Platform function packaging and isolation, realizing a global view of business processes

3 Refactoring-continuous optimization

Precipitation comes from business needs, but often lags behind new needs. For people other than designers, maintaining the "building blocks" of others will often step on a lot of pits, and it is better to rewrite it yourself. This is why every team is talking about precipitation, but it is capable of horizontal reuse, and even the ability to continuously reuse within the same team is very rare. Although there is no perfect solution to this phenomenon, I personally suggest to take a positive attitude towards these "building blocks":

• Analyze the historical background and understand the technical and business background of the emergence of "building blocks"
• Clarify the problems that the ability can solve, and the unsuitable scenarios
• Analyze the current business needs and whether it can be reused directly after reconstructing the capability
• Communicate with creators and evaluate reconstruction plans

There is no emphasis on the ROI comparison between refactoring, reuse and rewriting, because in my opinion, even if the former is more expensive, the process of refactoring is beneficial to personal technical growth and team culture unity. Compared with the continuous overthrow and inventing of new "building blocks", the process of continuous optimization is to constantly review and reflect on the experience of oneself and others, and to see the historical pits in order to avoid the emergence of new risks.

4 Integration-flexible construction

Standards can be implemented. In addition to having enough "building blocks" library at hand, the more important point is to have a flexible and convenient "glue" to complete the rapid construction and flexible adjustment of business functions. In the scenario of supply chain finance, business needs are mainly embodied in various business processes, such as issuance/transfer/clearing and so on. In order to simplify the construction of "building blocks" and flexibly reuse the underlying capabilities, we designed a business-oriented service orchestration engine based on the following goals:

• Standardization: follow the design protocol and shield general technical details that are irrelevant to the business
• Plug-inization: friendly to "building blocks", sustainable accumulation and reuse of new capabilities
• Business-oriented: business-oriented process orchestration with business description capabilities
• Configurable: process orchestration can be completed through configuration, it is best to achieve visual configuration

5 Products-Big Picture of Business

"Building blocks" + "glue" can meet the low cost and high expansion of technology landing, but from a business perspective, a big picture is needed to depict the global capabilities and functional processes of the business line. Not involved in this article.

Three practices-business architecture standard program

As mentioned earlier, consensus formed by documents alone does not have sufficient constraints on technology and is extremely difficult to maintain. Therefore, based on the principles of the above-mentioned statute, we have built a set of standardized business architecture design schemes, constraining business applications through componentized tooling, and forming a team consensus. A standard business application architecture is as follows:

1 Components-specification technical details

Constrain the behavior of general technical details through componentized conventions, including but not limited to:

transaction model

The core transaction model that describes the business process is used to control the advancement of the state and maintain the association with the business model.

Warehousing behavior

The general behavior of the data persistence layer, including lock query/insert/update/normal query, etc.

Transaction template

Define transaction boundaries to ensure transaction consistency of business logic in the template; support idempotent capabilities.

universal business template

Define business logic boundaries without transactional guarantees, but include general capabilities such as exception handling/log embedding.

General query template

Define the logical boundary of the query, similar to the general business template, but mainly for query scenarios such as single item/batch/pagination.

message

Simple encapsulation of message middleware, adapting to business application specifications, and reducing configuration costs.

scheduling

Simple encapsulation of dispatching middleware, adapting to business application specifications, and reducing configuration costs.

service open

The api component standardizes external service capabilities, identifies service definitions and service implementations through annotations, automatically generates interface documents, describes interface parameters/returns/business domains/error codes, etc.

Other-Log/Exception Handling/Request Parameters/Return Type

No expansion here.

The above are the technical details that all business applications will encounter. The idea of shielding details with components is not complicated. The point we want to express is: as much as possible to precipitate and reuse technical components, and use the results of others as much as possible, and do not repeat Build and focus on the business!

2 Domain-Focus on business modeling

Again, for business technology, business modeling is the core, business modeling is the core, and business modeling is the core! The original intention and plan of this article are to liberate the development and face the design and thinking of the core business. This section only gives the basic requirements of the field output, and will be detailed in the [Case Analysis] later.

Domain entity

The core of modeling is to abstract domain entities and their association relationships. Different business scenarios and design ideas will vary greatly, and they will eventually be reflected in one or more domain models. It is necessary to clarify the domain models that need to be included in each transaction model under different business processes (more abstract, and will be detailed in [Case Analysis] later).

field storage

Define the data model and its correspondence with the domain model (various converters). Based on the warehousing components mentioned above, configure database tables and connections to achieve business behaviors such as lock query/insert/update/general query.

Domain Services

Based on business behavior, abstract the atomized domain service capabilities. The service does not need to focus on data warehousing, business processes, and only abstracts the native capabilities of domain entities. Take the accounts receivable model mentioned in the above article as an example, at least it needs to include:

• Creation of accounts receivable
• Split/circulation of accounts receivable
• Destruction of accounts receivable

And so on basic behavior.

Transaction entity

The business entity used to carry the transaction process, the business instance of the above transaction model, is internally associated with one or more domain entities.

Trading Warehouse

Used to control the warehousing behavior of transaction entities and internal entities in various fields.

3 Service Orchestration Engine-Building Blocks + Glue

Any application involving complex business processes needs to introduce a process engine to orchestrate the flow of state machines. There are many mature process engine frameworks in the industry, and there are also many simplified versions that are sufficiently usable. However, as mentioned above, the advantages of this type of general-purpose engine are also its biggest weakness: excessive flexibility cannot restrict the design style, and a large number of business details will be scattered among nodes in different states, which is not intuitive and difficult to maintain. Starting from our own needs, we designed a business-oriented service orchestration engine to constrain technology in a way that follows business design specifications and describe business processes in an intuitive form. Compared with traditional process engines, its business friendliness is mainly reflected in:

• Constraint business model: need to clearly specify business transaction model/status and warehouse definition, and follow business design specifications
• Managed warehousing behavior: only need to configure the business model and warehousing implementation, no longer need to pay attention to the timing and details of data persistence
• Orchestration of domain services: through the transfer layer, the domain services are opened to the engine for free orchestration. The atomic capability of the domain is the smallest execution unit of engine orchestration
• Flexible increase and decrease of status: state transitions and business behaviors in the process can be flexibly plugged and unplugged
• Support the expansion of "building blocks": package reusable domain service portfolios to form a fixed pattern, which can be reused as "building blocks" in other processes

In general, the service orchestration engine shields technical details based on common components, focuses on the orchestration and reuse of business behaviors, and “glues” the “building blocks” to orchestrate business processes that meet business needs.

Four summary

Starting from the actual pain points of the business technical team, this article tries to unify the team’s technical style by combining business architecture design specifications (theoretical standards) and business architecture standard solutions (engineering constraints), releasing technical students from the details and focusing on technical capabilities Accumulation and thinking about business value. The ideas I hope to convey are:

• Restrict technical details with standards: reduce the flexibility of business design, but also to reduce costs
• Use technical tools instead of documents to promote standards: components that continue to accumulate are better than non-binding documents
• Continue to refactor rather than create new wheels: face up to the past output of yourself and others, continuous improvement can bring growth
• Pay attention to business modeling: think about business and industry, arm yourself with DDD, and improve modeling thinking and ability

Due to space limitations, [Case Analysis] will be detailed in another post in the follow-up. Some immature ideas in the article are welcome to correct me.

---

Cloud Developer Community

World Book Day, come and read

April 23 is the 26th World Book Day, and the Alibaba Cloud Developer Community launched the "Record the Road to Reading, Influencing People in the Same Industry" activity. 6 Alibaba technical people shared the good books they have read with the students, and the developers collected the scriptures. Ge also released the most popular e-book.

Click on the link: https://developer.aliyun.com/topic/worldreadingday?utm\_content=g\_1000264434 , recommend books that have influenced you, let’s read together~

Copyright Statement: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users. The copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.