The Importance of a Unified Language and Model‑Driven Design in Large‑Scale Distributed Systems

With the hype around SOA, micro‑services, and the support of open‑source projects such as Dubbo, Spring Cloud, and Netflix OSS, the technical threshold for building large distributed systems has become very low. However, this does not mean that constructing such systems is easy, because every system reflects domain knowledge. The author records insights gathered over years of system development for reference.

Unified Internal Common Language

Question:

1. SPU = SKU

A: Give me the SPU under category X. B: Give the SKU under category X to A.

2. ID = CODE

A: I give you the mall ID, you give me the mall information. B: A gives me the mall CODE, and I query using the CODE.

To solve this, all team members should be aware of the need to create a common language and constantly remind each other to focus on basic concepts, using this language whenever possible. Minimizing jargon and using a shared language helps communication become clearer and more precise.

The common language connects all parts of the design and establishes a prerequisite for smooth teamwork. Large‑scale projects can take weeks or months; initial concepts may turn out to be incorrect or outdated, and new design elements may emerge. Without a shared language, none of this is feasible.

Creating such a language is not a one‑day effort; it requires hard work to identify key elements, define domain concepts, find appropriate terminology, and start using it. Some concepts are easy to discover, others are not.

The importance of a common language is obvious, yet it is often not elevated to a high priority, leading to low internal communication efficiency. Reinforcing the abstraction and use of this language across the organization will not instantly boost efficiency, but it is worthwhile.

Model‑Driven Design (MDD)

When product managers (software analysts) and business domain experts (clients) collaborate, they identify fundamental domain elements, clarify relationships, and create a correct model that captures domain knowledge. Developers may find that some concepts in the model cannot be expressed directly in code, so they use the model as inspiration, adding their own design elements. As development proceeds, more classes are added, widening the gap between the original model and the final implementation, making it hard to guarantee good results.

If developers participate in requirement discussions and obtain a clear, complete view of domain knowledge before coding, their design work becomes more efficient. The best practice is to tightly couple domain modeling with system design, considering implementation concerns during modeling and adjusting the direction promptly. This yields an effective domain model that developers can easily translate into code.

When building a software application, a large portion is not directly related to the domain but serves as infrastructure or supporting services. It is advisable to keep the domain‑related part of the application as small as possible compared to the rest, because typical applications contain extensive code for database access, file/network I/O, and user interfaces.

Therefore, a complex program should be divided into multiple layers, each with a cohesive design that depends only on the layers below it. Following standard architectural patterns ensures low coupling between layers. Domain‑related code should be concentrated in a dedicated layer, isolated from UI, application, and infrastructure code. Domain objects focus solely on expressing the domain model, allowing the model to evolve into a rich, clear representation of business knowledge that works reliably.

Common layered architecture:

Layer

Description

Presentation Layer

Displays software functionality and information to users

Application Layer

Coordinates application logic, excludes business logic and object state, contains session context

Domain Layer

Core business logic, maintains business object state, contains complete domain information

Infrastructure Layer

Entity persistence, common libraries, foundational services

Layering inevitably raises boundary‑definition issues, especially for large distributed applications where each layer can become massive. The solution is to first partition modules by domain, then apply layering. Clear module and layer definitions prevent code chaos and reduce management costs.

Cohesion starts at the class and method level but can also apply to modules. Two types of module cohesion are communication cohesion and functional cohesion. Functional cohesion (grouping strongly related business logic) is considered best practice. While striving for cohesion, many objects will still be related, forming complex relationship graphs (one‑to‑one, one‑to‑many, many‑to‑many). The challenge is to keep models as simple and understandable as possible, often by removing unnecessary associations, adding constraints to reduce multiplicity, or converting bidirectional associations to unidirectional ones.

Interface Design Principles

Ensure idempotency of interfaces as much as possible, both for reads (trivial) and writes (address concurrency with optimistic locking, etc.).

Design interfaces to be degradable.

After requirements are fixed, define interfaces and data models first; document protocols and fields thoroughly in JavaDoc and Swagger API Docs.

Start domain‑layer interfaces with a relatively large service boundary, then refactor into smaller ones based on business needs; focus on the appropriate micro‑service scope rather than arbitrarily shrinking services.

Interfaces must be backward compatible, include version numbers, and consider legacy versions when underlying data structures change, especially for C‑end products.

Prefer stateless interfaces; if state is required, split the interface by state.

Avoid over‑abstracting interfaces (e.g., public Map query(Map map) ), which are hard to maintain, but also avoid under‑abstracting, which leads to an explosion of interfaces. Abstract when business stabilizes.

Source: http://www.yangguo.info

SDCC 2017 • Shanghai will be held from March 17‑19, 2017, featuring three technical summits and 24 speakers, gathering CTOs, architects, and tech directors from leading Chinese internet companies to discuss operations, databases, and architecture. Click Read Original for details and registration. At the same time, this public account provides a discount code 「SDCCVIP」 for ¥100 off (limited quantity) and a group‑buy offer of ¥1500 off for five tickets.