In cross-departmental development, there is always some parameter transformation logic that involves bilateral domain logic. Who should do this transformation logic? The following uses a simple example to demonstrate the process of the dispute, and gives some thinking.

1. Dispute Examples Demand background

Users to buy two pieces of goods, “buy one get one free” “sales department” care independently of the two goods (different commodity prices and sales promotion is not the same), “” stock department don’t care about buy a send a, tell me deduct two parts inventory can,” the settlement department “call” the inventory department “of interface exactly should combine” buy one get one free “quantity for two?

2. Scheme 1: Settlement as “glue layer”

  • Inventory domain (department) : thinks that it provides API, and the user splices parameters according to its API (inventory does not care about the master gift, but only the quantity, and merges the quantity according to the standard of inventory)
  • Promotion domain (department) : it thinks that it provides API, and the user splices parameters according to its API (promotion cares about the main gift, and does not merge the quantity according to the promotion standard)
  • Settlement page department: Everyone thinks that settlement is the glue layer, and it is natural to connect each transaction subdomain. The settlement department needs to process parameters according to its needs before invoking each system. The settlement page needs to learn the implicit interface knowledge of each subdomain.

3. Settlement as the overall structure of glue

The overall formation of each subdomain is comfortable and is grand; The settlement page needs to learn the differences of each subdomain and wrap them up, and the settlement page needs to respond to changes in each subdomain.

4. Scheme 2: The settlement page is a core business subdomain with peer-to-peer architecture

What if the settlement domain considers itself to be a core business domain like inventory and should not be coupled to other domains?

  • The settlement page establishes a “general model standard”, passing that each sub-domain is a “general model”, and the change of each sub-domain has a lower probability of affecting settlement.
  • Each subfield, such as Inventory and Promotion, converts the “general parameters” of the settlement page into its own format.
  • Each subdomain such as “inventory” and “promotion” needs to learn “common model standards” for settlement.

5. Scheme 2 is used as an example

In the example above, the change to the settlement page to pass inventory and promotion are both apples, and the inventory and promotion themselves decide whether to merge.

  • More flexibility: If the inventory has a scenario where the same item does not need to be merged, or a scenario where part of the inventory needs to be merged, the settlement page will not be aware of it.

6. Scheme comparison

Plan 1: Simple, direct and original.

  • Glue and core business domains are clearly separated, and changes are concentrated in the glue layer.
  • As the service complexity increases, the glue layer has more responsibilities, which makes the complexity of the glue layer difficult to maintain.

Plan TWO: complex and flexible.

  • Increased difficulty in management communication: The glue layer upgrades the business domain and peer architecture, which requires different departments to recognize the “common model”.
  • More stable overall response to complex business: logic is concentrated in specific sub-domains, and each sub-domain responds to needs individually and is more specialized and cohesive.
  • Difficulty: rationality of “general model” of different business domains.

7. Paradox and thinking of “General model” in Scheme 2

The general model contradicts the subdomain division

The original intention of dividing different subdomains is that different subdomains can independently design “subdomain proprietary models” without affecting each other. From this point of view, subdomain division is opposed to “universal model”. In fact, there is no universal model applicable everywhere, which needs to be made clear.

Local universal model

So what is the “general model” of option 2? While there is no universal model, if we add scope, what about the subdomains of transactions (not counting the vastly different subdomains such as finance)? Is it possible to have a “general model” that several subdomains of a transaction can reuse to some extent?

Below: one step closer, can be in “general model”, on the basis of appropriate transformation, eliminate each subdomain must don’t care about the properties of the formed between the “general model” and “proprietary model” for communication between the model and produce each subdomain universal model (such as “general inventory model”, “promotion of general model”)

Different solutions have a life of their own and are suitable for different scenarios, which are difficult to judge by a single “good” or “bad” sentence.