Introduction:When you first launched the application, have you ever felt unable to start in the face of business framework construction? Maintaining online applications and facing a lot of historical burden, are you avoiding the pit and falling into the mire? Why are the same business applications with different design styles? Why is the original design always beyond recognition after multiple iterations? When newcomers come to the team, how can they quickly understand the business without being tortured by a large number of technical details? If you also have these problems, I hope this article can provide some help.
Author Mu Chen
Source: Ali technical official account
When you first launched the application, have you ever felt unable to start in the face of business framework construction? Maintaining online applications and facing a lot of historical burden, are you avoiding the pit and falling into the mire? Why are the same business applications with different design styles? Why is the original design always beyond recognition after multiple iterations? When newcomers come to the team, how can they quickly understand the business without being tortured by a large number of technical details? If you also have these problems, I hope this article can provide some help.
I. original intention
1. Detail split architecture
There are many mature application frameworks in the industry. Both springmvc / springboot and sofaboot have given clear specifications for the engineering structure, and the responsibility boundary seems very clear. However, in practice, no matter how simple the business application is, it can not avoid the dispersion of business logic, breaking the module boundary and implicit coupling. Scattered business details will inevitably lead to the fragmentation of the application architecture. If there is no continuous reconfiguration and adjustment, it will eventually become complex and bloated (of course, on the premise of continuous new demand). The old people are silent and the new people cry, so they can only rely on the strong man to redo 2.0. The main reasons are:
- The flexibility of the framework is too high: the application framework gives engineering specifications rather than business design specifications, which retains great flexibility for developers. A business function can be implemented in many ways.
- Insufficient binding force of Architecture: the construction and maintenance of business architecture is the result of different people’s investment in different periods. Different design thinking, self requirements and project schedule pressure will have an impact on the current situation of the application.
By analogy with the relationship between law and morality, the general framework restricts the “legal” bottom line of technical coding, and the design principle is the “moral” requirements of developers. In a simple business scenario, meeting requirements is the first priority, and the demand for design capability is not prominent. However, in the case of multi-party collaborative business teams (the real situation is mostly the case), without a unified “ethical standard”, it will be difficult to form a joint force to complete complex projects. The Java Development Manual (Alibaba java development specification) has taken a great step on the road of promoting coding standards, greatly improved the professional quality of engineers and greatly improved the “moral consensus”. In the field of business architecture design, can a set of “design specifications” for business R & D students be established in at least one problem domain.
2. Technical precipitation loss
On the other hand, after entering Alibaba, although I don’t have much R & D experience, I have been in contact with many excellent designs. Whether these outputs are optimal or not, they reflect the good wishes of technical students for excellent design and strong landing ability, and indeed effectively ensure business development in a certain historical period. However, what puzzles me is that although each business project and business product can precipitate some reusable components or frameworks, and the students involved in R & D can also summarize a set of design principles and practical experience for future needs, these wealth is always difficult to maintain and inherit. The possible reasons are (I don’t know much about the R & D experience of front-end / test / data / platform, and this is only for the R & D of front-line business):
- Adhere to design results rather than design principles: R & D students with successful experience tend to apply the current business scenario with their previous architecture design. This idea itself is not right or wrong, but if the nail does not match the hammer, it will often introduce a lot of additional costs in the short term, but lose the original design advantage. In the face of specific problem areas, only by adhering to the consistent design principles and combining many factors in the process of demand analysis, can we create a design that truly meets the current and future needs.
- Like to build new wheels rather than continuous reconstruction: the design principles and code cleanliness of R & D students may be a kind of “metaphysics”. It is a more deterministic norm to ignore the previous code. In fact, it is not difficult to understand. Even if they are all DDD schools, they may not agree with each other during scheme communication; Even if the architecture design is agreed after concession, the style of coding implementation is still leading. Is it more important to understand the previous design ideas and code habits, or is it more important to complete the business requirements on time? Is it easier to rewrite according to the design style you are good at, or is it easier to continuously reconstruct and optimize other people’s “outdated” designs?
- Rely on document inheritance rather than instrumental reuse: for newcomers, no matter how many suggestions and quick start guides in the document are better than an out of the box project demo; People who continue to develop mature applications will not resist the temptation of temporary code in exchange for getting off work early because of the capitalized precautions in historical documents, unless you have to give up due to the mandatory constraint of compilation / deployment failure in the application project.
Compared with the inefficient cooperation caused by the lack of “design specification”, it is more regrettable that the precipitated “specification prototype” is easily abandoned. The daily work of business R & D is essentially to disassemble the complexity of the problem domain and break down the sub problems one by one with multiple ideas of hierarchical decoupling / instrumentalization / platform / business abstraction. If some sub problems have been well solved, why not stand on the shoulders of predecessors? Give up the tangled mentality of whether to build a new “wheel”. Perhaps we need to build a “building block” mentality.
Second idea: business architecture design specification
Combined with the technical practice of ant chain application technology team in recent years, we try to build a set of business architecture design specifications that may meet more business scenarios from our own needs. Under the emphasis, this paper puts forward the solution idea from the limited problem domain, and does not expect to become a general solution. If other business lines have similar pain points, I hope they can learn from them.
- Standard: unify business design framework and simplify technical details with standardized architecture
- Precipitation: continuously precipitate “building blocks” from business scenarios
- Reconstruction: continuously reconstruct the “building blocks” to reduce repeated construction
- Integration: rapid integration based on business service orchestration engine
1 standard – reduce detail
Ideally, business technology only needs to focus on domain modeling, but in reality, it has to consider more general technical details. Taking the simplified accounts receivable issuance process under the supply chain finance scenario as an example, the following should be considered:
- Domain modeling: Design of accounts receivable domain model and its behavior
- Process layout: the design of process model and the design of state machine of distribution process
- Data conversion: bidirectional conversion of domain model < – > data model and process model < – > Data Model
- Concurrency control: Design of service lock mechanism
- Business idempotent: idempotent control of each business phase in a process
- Exception handling: exception capture, error code Convention
- Monitoring alarm: summary log, exception log, boundary log
Among the items not fully listed above, except “domain modeling”, they are basically irrelevant to specific business, but they are indispensable for a stable and reliable business application. If a standardized framework scheme can be established and a large number of details irrelevant to business can be solved with unified specifications, will business technology students really focus on “domain modeling”?
2 – capacity reuse
Precipitation and reuse are the most common words in the technology group, which shows the high degree of recognition. Capacity reuse is not limited to form and granularity. It can effectively reduce technology cost and improve business scalability. It is a good precipitation and can be used as a “building block” for subsequent use. Taking the ant chain application technology team scenario as an example, the capabilities precipitated in recent years include but are not limited to:
- Engineering specification series: constraint coding specification and boundary interface definition style, log printing, exception handling, warehousing behavior, state machine, etc
- Read write separation mechanism: shield the design conflict between transaction requirements and query requirements on the data model, reduce the design complexity and improve the query performance and flexibility
- Online banking core: improve the scalability of online banking core signature in different business processes
- Contract Chaining: improve the scalability of smart contract docking in different business processes
- Configuration center: flexibly define and manage various configuration items required by business processes
- Product center: platform functions are packaged and isolated to achieve a global view of business processes
3 refactoring – continuous optimization
Precipitation comes from business needs, but it often lags behind new needs. For people other than designers, maintaining other people’s “building blocks” will often step into many pits, but it’s better to rewrite them yourself. This is why every team is talking about precipitation, but the ability to reuse horizontally and continuously within the same team is very few. Although there is no perfect solution to this phenomenon, I suggest taking a positive attitude towards these “building blocks”:
- Analyze the historical background and understand the technical and business background of “building blocks”
- Identify the problems that the capability can solve and the scenarios that are not applicable
- Analyze the current business requirements and whether the capability can be reused directly after reconfiguration
- Communicate with the creator and evaluate the reconstruction landing scheme
The ROI comparison between the two schemes of refactoring, reuse and rewriting is not emphasized here because in my opinion, even if the former cost is higher, the process of refactoring is beneficial to personal technology growth and team culture unity. Compared with constantly overthrowing and inventing new “building blocks”, the process of continuous optimization is to constantly review and reflect on the experience of yourself and others, and see the pit of history, so as to avoid the emergence of new risks.
4 integration – flexible construction
The standard can be implemented. In addition to a sufficient “building block” library, it is more important to have a flexible and convenient “adhesive” to complete the rapid construction and flexible adjustment of business functions. In the scenario of supply chain finance, business requirements are mainly reflected in various business processes, such as issuance / transfer / clearing, etc. In order to simplify the building of “building blocks” and flexibly reuse the underlying capabilities, we designed a business oriented service orchestration engine based on the following objectives:
- Standardization: follow the design specification and shield the general technical details irrelevant to the business
- Plug in: friendly to “building blocks”, sustainable precipitation and reuse of new capabilities
- Business oriented: business oriented process arrangement with business description capability
- Configuration: process arrangement can be completed through configuration, and it is best to achieve visual configuration
5 product – Business Map
“Building blocks” + “bonding” can meet the low-cost and high expansion of technology implementation, but from a business perspective, a global map is also needed to describe the global capabilities and functional processes of the business line. Not covered in this article.
III. practice – Business Architecture Standard Scheme
As mentioned earlier, the consensus formed only by documents does not have enough constraints on technology and is extremely difficult to maintain. Therefore, based on the principles of the above regulations, we have built a set of standardized business architecture design scheme to restrict business applications by means of component chemical materialization and form a team consensus. A standard business application architecture is as follows:
1 components – Specifications and technical details
Through the componentization agreement, the behavior of restricting the general technical details includes but is not limited to:
The core transaction model describing the business process is used to advance the control status and maintain the association with the business model.
General behavior of data persistence layer, including locking query / insert / update / general query, etc.
Define transaction boundaries to ensure the transaction consistency of business logic in the template; Idempotent capability is supported.
General business template
The business logic boundary is defined without transactional guarantee, but it includes common capabilities such as exception handling / log embedding point.
General query template
It defines the query logic boundary, which is similar to the general business template, but mainly for query scenarios such as single item / batch / paging.
The simple encapsulation of message oriented middleware can adapt to business application protocols and reduce configuration costs.
The simple encapsulation of scheduling middleware can adapt to the business application protocol and reduce the configuration cost.
API components standardize external service capabilities, identify service definitions and service implementations through annotations, automatically generate interface documents, describe interface parameters / returns / business domains / error codes, etc.
Other – log / exception handling / request parameters / return type
There is 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 focus we want to express is: precipitate and reuse technical components as much as possible, use the achievements of others as much as possible, don’t build repeatedly, and focus on 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 scheme of this paper are to liberate the development and face the design and thinking of the core business. This section only gives the basic requirements for field output, which will be detailed in [case analysis] later.
The core of modeling is to abstract domain entities and their relationships. Different business scenarios and design ideas will vary greatly, and will eventually be reflected in one or more domain models. It is necessary to specify the domain models that need to be included in each transaction model under different business processes (more abstract, and then detailed in case analysis).
Define the data model and its corresponding relationship with the domain model (various converters). Based on the storage components mentioned above, configure database tables and connections to realize business behaviors such as lock query / insert / update / general query.
Abstract the atomized domain service capability based on business behavior. The service does not need to focus on data warehousing or business processes, but only abstracts the native capabilities of domain entities. As an example, the accounts receivable model mentioned above should at least include:
- Creation of accounts receivable
- Splitting / circulation of accounts receivable
- Destruction of accounts receivable
And so on.
The business entity used to carry the transaction process is the business instance of the transaction model above, which is internally associated with one or more domain entities.
It is used to control the warehousing behavior of trading entities and internal entities in various fields.
3 service orchestration engine – building blocks + glue
All applications involving complex business processes need to introduce process engine to arrange the flow of state machine. There are many mature process engine frameworks in the industry, and there are many simplified versions available. However, as mentioned above, the advantages of this kind of general engine are also its biggest weakness: too strong flexibility can not 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 by following the business design specification and describe the business process in an intuitive form. Compared with the traditional process engine, its business friendliness is mainly reflected in:
- Constraint business model: clearly specify the business transaction model / status and warehouse definition, and follow the business design specification
- Managed warehousing behavior: you only need to configure the business model and warehousing implementation without paying attention to the timing and details of data persistence
- Choreographing domain services: through the transition layer, the domain services are opened to the engine for free choreography. The atomic power of the domain is the smallest execution unit of engine choreography
- Flexible increase / decrease status: the status transition and business behavior in the process can be plugged in and out flexibly
- Support “building block” extension: package reusable domain service composition to form a fixed pattern, which can be reused in other processes as “building blocks”
In general, the service orchestration engine shields the technical details based on common components, focuses on the orchestration and reuse of business behaviors, and “glue” the “building blocks” to compile and discharge the business processes that meet the business requirements.
Starting from the practical pain point of the business technology team, this paper attempts to unify the technical style of the team with the idea of business architecture design specification (theoretical standard) and business architecture standard scheme (engineering constraint), release the technical students from the details, and focus on the accumulation of technical ability and thinking about business value. The ideas you want to convey are:
- Constraining technical details with standards: reducing the flexibility of business design is also to reduce costs
- Promote standards with technical tools rather than documents: continuously precipitated components are better than non binding documents
- Continuous reconstruction rather than creating new wheels: face up to the output of yourself and others, and continuous improvement can lead to growth
- Pay attention to business modeling: think about business and industry, arm yourself with DDD and improve modeling thinking and ability
Due to space constraints, the [case analysis] will be detailed in another article. Some immature ideas in the article are also welcome to be corrected.
Alibaba cloud developer community
World Book Day, come and read
April 23 is the 26th World reading day. Alibaba cloud developer community launched the activity of “recording the way of reading and influencing peers”. Six Alibaba technicians shared the good books they had read for the students. The developer Sutra Pavilion also launched the most popular e-books.
Click the link: https://developer.aliyun.com/topic/worldreadingday?utm \_ content=g\_ 1000264434, recommend books that have influenced you. Come and read together~
Copyright notice:The content of this article is spontaneously contributed by Alibaba cloud real name registered users, and the copyright belongs to the original author. Alibaba cloud developer community does not own its copyright or bear corresponding legal liabilities. Please refer to Alibaba cloud developer community user service agreement and Alibaba cloud developer community intellectual property protection guidelines for specific rules. If you find any content suspected of plagiarism in the community, fill in the infringement complaint form to report. Once verified, the community will immediately delete the content suspected of infringement.