On
STRATEGIC ADJUSTMENT OF TECHNICAL ARCHITECTURE BASED ON DDD THINKING

1. brief description of the case

the epidemic in 2020 has a particularly large impact on the tourism industry, the company level has made organizational adjustments, the hotel business side has undergone tremendous changes, and the new business team has encountered new production and research efficiency problems when promoting some actual needs, mainly reflected in the product to cooperate with multiple technical teams each time, and the overall technical architecture is disconnected from the business.

COMBINED WITH THE SUCCESSFUL EXPERIENCE OF THE PREVIOUS DDD LANDING, THE HOTEL’S TECHNICAL SIDE TOOK THE INITIATIVE TO LAUNCH A TECHNICAL ARCHITECTURE STRATEGIC ADJUSTMENT BASED ON THE DDD IDEA IN MID-2021, INVOLVING ORGANIZATIONAL STRUCTURE ADJUSTMENT, SYSTEM ARCHITECTURE ADJUSTMENT, ETC., AND FORMULATED SOME CORE TECHNOLOGY SOLUTION STANDARDS. FINALLY, BASED ON THIS STRATEGIC ADJUSTMENT, LOOK AT THE ROLE PLAYED BY CONWAY’S LAW AND DDD THOUGHT.

2. case background and problem analysis

1. background

at the beginning of 2020, the global outbreak of the new crown epidemic had a relatively large impact on the tourism industry. in may 2020, the company level made relatively large adjustments, first of all, the establishment of the air ticket destination business group, air ticket and hotel as the largest business unit of the two companies from independent operation to a business group, followed by the unification of the service, user experience and other teams, unified responsibility for the business group, and at the same time formulated the strategic goal of machine wine crossover (can be simply understood as the user can buy the hotel after purchasing the ticket).

in the face of these organizational structure and business architecture adjustments, how should the system architecture evolve to support these changes? with this in mind, let’s look at some of the problems that have actually been encountered.

2. problems and performance

2.1 product spit
  • almost every need to communicate with multiple technical teams, cooperation trouble
  • many technical solutions require upgrades often to reach consensus
2.2 extended questions
  • seemingly simple requirements, the link is very long, there is always a team even if there is no logical modification to do the things to pass through
  • when discussing technical solutions, different teams disagree on who implements a certain logic, and the essence is that the boundaries are not clear enough
3. problem analysis 1

let’s first look at the interaction diagram at the core of the main process:

(Note: In the figure, List represents the list page, Detail represents the detail page, Booking represents the booking page, and Order represents the order page)

through the interaction process in the above figure, we can summarize the following problems:

  • the team involved in all the core processes is the quotation team, and the quotation team is the back-end team, which is relatively low-level
  • the user-side cross-page interaction unification needs to be done by the underlying quote team
  • the underlying modification will drive the entire link to be modified (typical example: new fields for basic data)
  • the positioning of the quotation team is based on the user’s calculation of the hotel room type, price and actual offer details, and the basic data and related logic do not want to perceive
4. problem analysis 2

continue to look at the core team and core design of the main process:

from the above diagram, we can summarize the following points:

  • many teams have an application layer on top of their domain layer
  • these application layers result in some things that upstream and downstream teams can do
  • many things, when anyone can do it, there may be a situation where no one wants to do it
  • the “golden oil” structure is suitable for the business upswing period, not for the stabilization period

3. case analysis and planning

1. Based on Explicit Architecture analysis

The above figure comes from the blog of herberto graca, a top foreign architect (https://herbertograca.com/), which integrates the “clear architecture” of DDD, onion architecture, neat architecture, and CQRS, which has many advantages, such as:

  • from the outside inward, the more inward the more biased the core principles, the core principles are relatively stable. the core principle is the regular domain layer, which provides core competencies
  • THE OUTER LAYER ADAPTS TO DIFFERENT BUSINESS SCENARIOS BASED ON CORE PRINCIPLES AND ASSEMBLES THE CAPABILITIES OF THE INNER LAYER. THE OUTER LAYER HERE IS THE REGULAR INTERFACE LAYER TO THE APPLICATION LAYER, MAINLY USING THE ACTIVE ADAPTER MODE, FOCUSING ON BFF AND THE AGGREGATION OF INNER LAYER CAPABILITIES
  • the inner layer does not depend on the outer layer, is not subject to business changes, pays attention to the expansion of capabilities, and completes the core policy implementation
  • the boundaries are obvious, especially between the domain layer and the application layer
  • CQRS MECHANISM, LOW COUPLING, THROUGH THE OUTER LAYER ASSEMBLY OF THE INNER LAYER ABILITY TO DYNAMICALLY ADAPT TO BUSINESS CHANGES, HIGH SCALABILITY
  • …

2. technical architecture concept

combined with the characteristics of a clear architecture, we think about the overall adjustment strategy of the technical architecture

  • CORE IDEA: THE OVERALL ARCHITECTURE IS BASED ON THE DDD LAYERING ARCHITECTURE, WHICH STRICTLY DISTINGUISHES BETWEEN THE APPLICATION LAYER AND THE DOMAIN LAYER
  • core action: the teams containing the core areas hand over their respective “application layers”, uniformly hand over to the downstream gateway teams, and form a unified application layer, and the things that these teams are responsible for become core areas

3. technical structure adjustment planning

around the above concept, the overall architecture diagram is expected to be shown in the following figure:

through the above diagram, several key points can be clarified:

(1) clarify the core of strategic adjustment

  • highlight the core areas, make the “big front desk” bigger (the interior is called the main station, here in order to facilitate the understanding of the adjustment of the name)

(2) the difference between clear and previous

  • the team responsible for the core area focuses on reusable capabilities, focusing on the improvement of core strategies and gameplay
  • the team responsible for the application layer focuses on business identification and expansion, focusing on business model design and assembly of downstream capabilities
  • the business converges into a team that understands the capabilities available downstream and can see the overall business from the big picture

4. analysis of advantages and disadvantages

around the above adjustments, analyze the advantages and disadvantages

(1) advantages (bias towards the middle office)
  • reduce the impact of the team: many needs, the product only needs to dock with one team at the front desk, that is, the “big front desk” team mentioned above
  • reduce the data link: the main process link becomes shorter, and it is easier to design technical solutions, locate and solve problems, typically the basic data link is no longer given downstream by the quotation team

these two points have been verified in practice to play a role in improving the efficiency of production and research.

(2) disadvantages and possible problems
  • in the short term, existing work habits change: data links change, requiring multiple teams to work together to land, and then adapt to the new link, while adapting to the new architecture
  • may bring instability to the upstream team: this is bound to bring some chores completely to the big front, if some people continue to do some chores or small needs, there may be personnel instability problems. at this time, you need to consider finding some core things, doing a good job of business modeling, etc. to improve

fourth, the case landing process

1. system architecture adjustment

  • apply attribution team adjustments
  • there are already logical attribution adjustments

the main thing to be done here is to hand over the application and logic of the “application layer” to the big front desk team, first ensure that the respective teams are responsible for the things that should be responsible, let the team responsible for the core areas actually be mainly responsible for the areas, and the rest is handed over to the big front desk

2. organizational structure adjustment

  • organizational structure should be adjusted on demand: for example, multiple gateways are merged into a large front desk, and some personnel intersections are completed with some needs
  • core personnel attribution team planning: here is mainly to review the core members, see if it is suitable for the field team or the big front, and make relevant adjustments if necessary
  • HC adjustment, recruitment plan follow-up: This time will increase the HC for the large front desk team as needed, and at the same time step up the recruitment rhythm to ensure that the personnel are in place as soon as possible, which can also avoid the impact of individual member instability on the overall situation
  • establishment of a business architecture group: to oversee and ensure restructuring while avoiding subsequent corruption

3. formulation of technical solution standards

3.1 data backhaul standardization
  • SPU dimension: Supply Chain – > Basic data (merchants, hotels, etc.) – > large front desk – > terminal
  • SKU Dimension: Supply Chain – > Quotation (Hotel Room Type and Price Concessions, Analogous to Commodities in E-commerce) – > Large Front Desk – > Terminal

Link governance according to SPU and SKU data backhaul standards: Compared with the previous links, the core needs a complete transformation of the basic data. We first made a domain division of the basic data based on the DDD idea, and then provided relevant external API services based on the domain, and then directly docked with the big front desk. The big front desk takes away the application layer application of the quotation team (the internal application name is mprice), first merges the original service into the existing application layer application, and then docks the basic data service API, from the 7 applications of the previous link directly down to 4 applications, plus some serial operation parallelization, not only the link is shortened, but the main process response time is reduced by 25%, and the effect is particularly good.

3.2 request processing standardization

3.2.1 program formulation

the diagram above is a few of the core processes of our main process of calculating the price paid by the user. focus on explaining [business promotion]: based on user portrait packaging, marketing activities that meet specific requirements (such as specific user identity), get a lower reserve price, and obtain higher profits.

next, let’s look at a practical problem: it is going to be over, and the business side wants to relax some commercial restrictions and give it to all users, how should the technical solution be designed? let’s first give two conventional technical solutions:

  • the foreground modifies the user’s identity, and the other teams are not aware of it. problem with the solution: the user identity has not changed in nature, and it is wrong to view the user identity, and other links will be affected.
  • the quotation team identifies the scenario and does special negotiation matching. the problem with the solution: the quotation normally provides the ability, and now it is necessary to provide customized functions, and the positioning difference is too large

conventional solutions have obvious problems, so what is the fundamental problem? in fact, the standard practice lacks the response to the [scene]!

let’s talk about identities and scenarios in business scenarios in conjunction with the following diagram.

after many internal discussions, the final conclusion was given:

  • identity: an identifier at any given moment that describes the user’s (userid) not a finite number of self-describing properties or characteristics affected by the act of the user itself and external conditions
  • scenario: who,when,where,”what happened,” what outcome or how

to give a few examples, such as hotel new customers, machine wine users are defined as users who have had certain designated consumption behaviors (bought hotels, bought airline tickets, etc.) for a period of time, through userid can directly get a clear result, this belongs to the identity; and the different ground yarn belongs to the scene, the reason is that for a clear userid, assuming that the permanent residence is beijing, this user wants to go to a place outside beijing this time, so as to match the “off-site”. here to pay attention to the limited number of identity characteristics of the limit, such as store new customers, for a user, whether he is a new customer of a store is normal is also clear, but we have nearly a million online stores, then it is not suitable for use as an identity, because we use userid to query his identity, each store is listed out of the cost is too large, this is more suitable for taking userid + store to query.

in our business scenario, the standard calculation is based on the normally defined identity, and if the identity cannot be used to match, it needs to be solved by using the scene.

based on the understanding of [identity] and [scene], for the previous problem, we give a more reasonable solution: the quotation provides the “mandatory use of the specified business promotion ability” foreground identification scenario, and assembles and uses the new capability. such quotations are still concerned about the improvement of capabilities, and the front desk is still responsible for the adaptation and assembly capabilities of the business, and the core is the standard use of identities and scenarios.

to add that, after adjusting the structure and implementing the technical plan, the entire architecture is viewed as a whole:

  • the domain layer can actually expose the capabilities, and the application layer can eventually expose the functions
  • because the application layer can assemble the capabilities as needed, it can show strong scalability; for the domain layer, it focuses on the reuse of capabilities, so it is more stable
  • the application layer assembles the domain layer capabilities, relying on standard identities and scenarios. either regular capabilities are used based on standard identities, or special abilities are enforced based on scenarios
  • the function is to solve the actual scene demands, the change is fast, so it is necessary to provide a lot of interfaces to complete some custom functions; the ability is to ignore the scene as much as possible, so that it is possible to achieve maximum reuse. resolving the conflict between the two requires the rational use of identities and scenarios.

3.2.2 parameter pass-through

Daily development we often encounter this situation, the need to use a parameter through many applications, to the use of special upstream applications, this parameter for the link involved in the transparent transmission of the team and application, without any business logic processing, in vain to increase development man-hours, disrupt the definition of the API. To solve this problem, the company’s internal business development and basic research and development jointly discussed the development of a new common component: QShareData. Each application can write some data to the QShareData component based on the request, the corresponding data ID is passed along with the trace, and other applications on the link can obtain the data written by other applications to the component through the data ID on demand, reducing some meaningless pass-through. Of course, this involves some permissions, performance and fair use issues, which need to be combined with the actual requirements and restrictions.

v. case summary

first, let’s review the famous conway’s law: the organization of design systems produces a design equivalent to a communication structure within and between organizations. conway’s law holds that there must be a match between the organizational structure and the system, but does not emphasize reasonableness

Next, let’s look at Conway’s law in DDD, which is at its core the system architecture-driven organizational structure. DDD is based on the business area, returning to the business, matching with the business, and it is easier to be reasonable.

I BELIEVE SOME PEOPLE WILL ASK: HOW CAN THE TEAM BE DIVIDED TO MATCH THE BUSINESS? THE ESSENCE IS TO MAKE THE CONSTRAINTS OF DDD THE GOAL OF DDD CHANGE, AND HERE ARE TWO POINTS:

  • BASED ON THE BUSINESS DOMAIN MODEL OBTAINED BY DDD, REVIEW AND ADJUST THE ORGANIZATIONAL STRUCTURE AND DIVIDE THE TEAM
  • starting from the business area structure, a network organizational structure is formed, and the flexibility of the organizational structure is maintained when the business changes significantly, which makes conway’s law work in reverse