Brief introduction: Have you ever felt at a loss about how to build a business framework when you first launched an application? Are you stuck with a lot of historical baggage in the face of maintaining an online app? Why is it that the same business application can be designed differently by different people? Why does the original design change beyond recognition after multiple iterations? When a newcomer comes to the team, how can he quickly learn about the business without being overwhelmed by technical details? If you have these problems, I hope this article can help you.
The author wood source sink | | ali technology to the public
Have you ever felt at a loss about how to build a business framework when you first launched an application? Are you stuck with a lot of historical baggage in the face of maintaining an online app? Why is it that the same business application can be designed differently by different people? Why does the original design change beyond recognition after multiple iterations? When a newcomer comes to the team, how can he quickly learn about the business without being overwhelmed by technical details? If you have these problems, I hope this article can help you.
The original intention
1. Detail fragmentation architecture
There are many mature application frameworks in the industry. Both SpringMVC/SpringBoot and Sofaboot have clear specification conventions for the engineering structure and seemingly clear boundaries of responsibility. But in practice, no matter how simple a business application is, it is inevitable that the business logic is scattered around, breaking the module boundaries and causing implicit coupling. Spreadline business details will inevitably lead to fragmentation of the application architecture. Without continuous restructuring and adjustment, it will always become complex and bloated (of course, if there are continuous new requirements). The old people will be silent and the new people will cry, and we can only rely on the Mute Man to redo 2.0. In my opinion, the main reasons are as follows:
Framework flexibility is too high: Application frameworks give engineering specifications rather than business design specifications, leaving developers with a great deal of flexibility that a business function can be implemented in many ways.
Insufficient constraint of architecture: the construction and maintenance of business architecture is the result of input by different people in different time periods. Different design thinking, different self-requirements and different project schedule pressure will have an impact on the status quo of application.
To draw an analogy between law and ethics, a generic framework constrains the “legal” bottom line of technical coding, while design principles are the “moral” requirements that developers place on themselves. In a simple business scenario, meeting requirements is the first priority, and design capabilities are not a priority. But in a multi-stakeholder business team (as is often the case), without a common “ethical standard”, it is difficult to form synergy to complete complex projects. “Java Development Manual” (Alibaba Java Development Statute) has taken a great step forward in promoting coding standards, greatly improving the professional quality of engineering staff, and greatly improving the “moral consensus”. Then in the field of business architecture design, is it possible to establish a set of “design specifications” for business R&D students in at least one problem domain?
Technical precipitation loss
On the other hand, although I have not had much research and development experience in Alibaba, I have come into contact with many excellent designs. No matter whether these outputs are optimal or not, they all reflect the good wishes of technical students for excellent design and strong implementation ability, and indeed effectively guarantee the business development in a certain historical period. However, what puzzles me is that although every business project and product can precipitate some reusable components or frameworks, and students involved in research and development can also sum up a set of design principles and practical experience oriented to future needs, these treasures are always difficult to maintain and inherit. Possible reasons include (I am not familiar with front-end/test/data/platform and other R&D experiences, and this is only for front-line business R&D) :
Adhere to design results rather than design principles: Successful R & D students tend to apply architecture designs of the past to current business scenarios. There is nothing wrong with this idea, but if the nail does not fit the hammer, it will often introduce a lot of extra cost in the short term, but lose the original design advantage. In the face of specific problem domain, only by adhering to the consistent design principles and combining many factors for dynamic trade-offs in the process of demand analysis, can we create a design that truly meets the current and future needs.
Predilation for new wheels rather than constant refactoring: While a student’s obsession with design principles and code cleanliness may be “metaphysical,” it’s not hard to understand why a student’s dislike of previous code is a more definitive norm. Even if they are all DDD schools, the scheme communication may not be mutually recognized; Even when the architectural design was agreed upon through concessions, the style of the coding implementation was the dominant one. Is it more important to understand previous design ideas and code idiosyncrasies, or to meet business requirements on time? Is it easier to rewrite your own design as you’re good at it, or is it easier to constantly refactor and optimize someone else’s “outdated” design?
Document inheritance rather than tool reuse: No amount of advice and quick start instructions in a document can be as good as an out-of-the-box engineering DEMO for newcomers. People who continue to develop on mature applications will not be able to resist the temptation to leave work early for temporary code just because of a note in capital letters in a history document, unless there is a mandatory constraint on compilation/deployment failure in the application project that forces you to abandon it.
It is even more unfortunate that a deposited prototype of a specification can be easily discarded than the inefficient collaboration caused by the lack of a design specification. In essence, the daily work of business research and development is to dismantle the complexity of the problem domain and break down the sub-problems one by one with multiple ideas of layered decoupling, instrumentalization, platformization and business abstraction. If the problem of partial elements has been solved well, why not stand on the shoulders of predecessors? Let go of the mentality of whether or not to build a new “wheel”. Maybe we need to build a “building block” mentality.
Second idea: business architecture design protocol
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 based on our own needs. It is important to note that the solution proposed in this paper is based on a limited problem domain and does not expect to be a universal solution. If other lines of business have similar pain points, hopefully we can learn from them.
Standard: Unified business design framework, simplified technical detail precipitation with standardized architecture: Continued precipitation of “building blocks” from business scenarios Refactoring: Continued reconstruction of “building blocks”, reduced duplication of building integration: Rapid integration based on business service choreography engine
Criteria – Reduce detail
Ideally, business technology would focus only on domain modeling, but in reality more general technical details have to be considered. Taking the simplified version of accounts receivable issuance process under the supply chain finance scenario as an example, the following considerations should be taken into consideration:
Domain modeling: accounts receivable model and its behavior in the field of design process choreography: process model to design and process of the state machine design data transformation: the domain model < – > data model and process model < – > data model of two-way transformation Concurrent control: the design of the locking mechanism business idempotent: process of each business segment in the idempotent control exception handling: Exception capture, error code convention monitoring alarm: summary log, exception log, boundary log
other
Most of the items listed above, with the exception of “domain modeling,” are not relevant to the specific business, but are indispensable to a stable and reliable business application. If we can establish a set of standardized framework solutions, with a unified specification to solve a lot of details unrelated to the business, will the business technology students really focus on “domain modeling”?
2 Precipitation — capability reuse
Precipitation and reuse are the most frequently looped words in the technology group, which shows the high degree of recognition. Capability reuse is not limited to the form and granularity, it can effectively reduce the cost of technology, improve business scalability, is a good precipitation, can be used as “building blocks” for subsequent use. Taking the Ant Chain Application Technology Team scenario as an example, the capacity of precipitation in recent years includes but is not limited to:
technical
Engineering specification series: constraint coding specification and boundary interface definition style, log printing, exception handling, warehousing behavior, state machine, etc
Read/write separation mechanism: Shielded the design conflicts between transaction requirements and query requirements on the data model, reduced the design complexity, and improved query performance and flexibility
E-bank core body: improve the extensible contract chain of e-bank core body signature in different business processes: improve the extensible platform class of smart contract docking in different business processes
Configuration Center: Flexible definition and management of various configuration items required by business processes Product Center: Platform functionality packaging and isolation to achieve a global view of business processes
Refactoring — Continuous optimization
Sedimentation comes from business needs that often lag behind new requirements. For non-designers, maintaining someone else’s “building blocks” can often lead to a lot of pitfalls, rather than rewriting them yourself. This is why every team talks about precipitation, but the ability to reuse horizontally, or even consistently within the same team, is rare. While there is no perfect solution to this phenomenon, my personal advice is to keep these building blocks in a positive perspective:
Analyze the historical background, understand the technical and business background of the emergence of “building blocks”, clarify the problems that this ability can solve, and analyze the current business needs in the inapplicable scenarios. Whether this ability can be directly reused and communicated with creators after reconstructing, and evaluate the implementation plan of reconstruction
The ROI comparison between Refactoring and Reusing and Rewriting is not emphasized here, because in my opinion, even though the former is more expensive, the process of refactoring is beneficial to both personal technical growth and the unity of team culture. Compared with constantly demolishing and inventing new “building blocks”, the process of continuous optimization is to constantly review and reflect on the experience of oneself and others, and to see clearly the pit of history, so as to avoid the emergence of new risks.
4. Integration — Flexible scaffolding
In order to achieve the implementation of standards, in addition to a sufficient library of “building blocks” at hand, it is more important to have flexible and convenient “adhesives” to complete the rapid construction and flexible adjustment of business functions. In the case of supply chain finance, business requirements are mainly embodied in various business processes, such as issuance/transfer/clearing and so on. In order to simplify “building blocks” and flexibly reuse underlying capabilities, we designed a business-oriented service choreography engine based on the following objectives:
Standardization: shielding common technical details that are not relevant to the business according to design specifications Pluginization: “building block” friendly, sustainable seperation and reuse of new capabilities Business-oriented, business-description process choreography configuration: Process choreography can be done through configuration, preferably with visual configuration
5 Products — business picture
“Building blocks” + “glue” can meet the low cost and high expansion of technology landing, but from the business perspective, a global picture is needed to describe the overall capabilities and functional processes of the business line. Not covered in this article.
Third practice – business architecture standard scheme
As mentioned earlier, consensus based on documentation alone does not impose sufficient constraints on the technology and is extremely difficult to maintain. Therefore, we built a set of standardized business architecture design scheme based on the principles of the above protocol, and constrained business applications through componentization and instrumentalization to form a team consensus. A standard business application architecture is as follows:
Component – specification technical details
The behavior of general technical details, including but not limited to, through componentization conventions:
Trading model
Describes the core transaction model of the business process to control state progression and maintain its relevance to the business model.
Storage behavior
Common behavior of the data persistence layer, including lock query/insert/update/normal query, etc.
Transaction template
Define transaction boundaries to ensure transactional consistency of business logic within the template; Support idempotent capabilities.
Common Business Templates
Defines business logic boundaries, no transactional safeguards, but includes common capabilities such as exception handling/log burial points.
Common Query Templates
Define query logical boundaries, similar to generic business templates, but mainly for single item/batch/paging query scenarios.
The message
The simple encapsulation of message-oriented middleware ADAPTS to business application protocol and reduces configuration cost.
scheduling
The simple encapsulation of scheduling middleware can adapt the business application protocol and reduce the cost of configuration.
Service is open
The API component specifies external service capabilities, identifies service definitions and service implementations through annotations, automatically generates interface documents, describes interface parameters/returns/business domains/error codes, and so on.
Others — logging/exception handling/request parameters/return types
I’m not going to expand it here.
The above are the technical details that all business applications will encounter, and the idea of shielding details with components is not complicated. The key point we want to express is: precipitation and reuse of technical components as far as possible, use the results of others as far as possible, do not repeat the construction, and focus on the business!
Domain 2 — Focus on business modeling
Again, business modeling is core to business technology, business modeling is core, business modeling is core! The purpose of this paper is to free up development to the design and thinking of the core business. This section only gives the basic requirements of the field output, which will be detailed in the “Case Study” later.
Domain entities
The core of modeling is to abstract domain entities and their association relations. Different business scenarios and design ideas will vary greatly, and eventually be reflected as one or more domain models. It is necessary to define the domain model that needs to be included in each transaction model under different business processes (more abstract, which will be detailed in [Case Study] later).
Field warehousing
Define the data model and its correspondence with the domain model (various converters). Based on the warehousing component mentioned above, configure database tables and connections to realize locking query/insert/update/ordinary query and other business behaviors.
Field service
Abstracts atomized domain service capabilities based on business behavior. This service does not care about data warehousing, does not care about business processes, only abstracts the native capabilities of domain entities. The accounts receivable model mentioned above, for example, needs to include at least:
Accounts receivable creation of accounts receivable split/transfer accounts receivable destruction and other basic actions.
Trading entity
The business entity used to host the transaction process, the business instance of the transaction model described above, is interrelated to one or more domain entities.
Trading, warehousing
It is used to control the warehousing behavior of trading entities and internal entities in various fields.
Service Choreographer Engine — Building blocks + Glue
Any application involving complex business processes requires the introduction of a process engine to orchestrate the flow of the state machine. There are a number of mature process engine frameworks in the industry, as well as a number of simplified versions that are readily available. However, as mentioned earlier, the strength of such a general-purpose engine is also its biggest weakness: too much flexibility does not constrain the design style, and a lot of business details are scattered among different state nodes, which is not intuitive and difficult to maintain. Based on our own needs, we designed a business-oriented service choreography engine to constrain technologies in accordance with business design protocols and describe business processes in an intuitive form. Compared with traditional process engines, its business-friendliness is mainly reflected in:
Constraints on the business model: need to explicitly specify the business transaction model/state and storage definition, follow the business design specification Custody storage behavior: only need to configure business model and the realization of warehousing, no need to pay attention to the timing of the data persistence and detail arrangement of field service: through the adapter layer, will open to the engine in free field service choreography. The atomic capability of the domain is the minimum execution unit of the engine choreography. Flexible states can be added and removed: Both state transitions and business actions in the process can be flexibly pluggable to support “building block” expansion: Packaged reusable domain service composition and form a fixed pattern, as the “building blocks” reuse in other process In general, the service choreography engine based on the common component shielding technical details, mainly focus on business behavior of choreography and reuse, to “glue”, “building blocks” to choreograph compliance with business needs of the business process.
Four summarizes
Starting from the practical pain points of the business technology team, this paper tries to unify the team’s technical style by combining the business architecture design specification (theoretical standard) with the business architecture standard solution (engineering constraint), freeing the technical students from the details and focusing on the accumulation of technical ability and thinking about business value. The ideas I hope to convey are:
Using standard constraints technical details: reduce the flexibility of business design, is also in order to reduce the cost with the tools of technology rather than the standard document: continuous precipitation component, is better than a non-binding document to refactor rather than to build new wheels: face up to themselves and others once the output, continuous improvement can lead to growth Attaches great importance to the business model: Think about your business and industry, arm yourself with DDD, and improve your modeling thinking and ability.