8 Design Principles for Business Middle Platforms and Distributed Services

From business to middle platform, abstraction modeling is required, consisting of level‑0 central modeling and level‑1 component modeling, both using entity abstraction.

First, gather enterprise functional requirements, illustrated by the functional requirement summary table (Figure 6‑1).

Next, identify the business or process entities corresponding to each requirement, distinguishing static (business) entities from process entities, and group similar entities together. Define domain capabilities as operations or commands applied to these entities.

Then, based on capability themes and entity relationships, define domain areas (business domains) and produce the abstraction table (Table 6‑1).

After defining multiple domain areas, architects combine them into centers, balancing entity aggregation, responsibilities, granularity, and operational independence (Figure 6‑2).

Business middle platforms follow eight design principles (Figure 6‑3):

1. Service Loose‑Coupling Principle

(1) Interface‑oriented implementation – services are consumed via defined interfaces without depending on specific implementations.

(2) Asynchronous event decoupling – services communicate through asynchronous message queues.

(3) Provider location decoupling – consumers discover providers via a service registry, avoiding direct IP/port knowledge.

(4) Version loose coupling – contracts remain backward compatible across upgrades.

2. Service Dependency Principle

(1) Valuable domain models – align services with business goals, keep logic simple, and derive insights from core business purposes.

(2) Minimal inter‑service dependencies – promote high cohesion and low coupling, expose capabilities via interfaces.

(3) Hierarchical capability entities – separate interface entities from capability entities and build layered structures.

(4) Delayed technical component dependencies – avoid unnecessary bindings and defer them to usage points.

3. Service Design Principle

(1) Optimize remote calls – choose synchronous or asynchronous modes based on scenario.

(2) Eliminate redundant data – remove unnecessary fields to reduce bandwidth and parsing complexity.

(3) Design coarse‑grained interfaces – map one interface to a complete use case or business scenario.

(4) Design generic interfaces – ensure broad compatibility across diverse applications.

(5) Isolate internal changes – prevent internal model changes from affecting clients.

(6) Interface‑first approach – define contracts before implementation.

(7) Downward compatibility – maintain stable interfaces after release.

4. Service Naming Principle

Use business‑oriented nouns for services and verbs for operations.

5. Service Granularity Principle

Services should be cohesive, complete, and independently fulfill a responsibility.

6. Stateless Service Principle

Statelessness is fundamental for scalability and high availability in microservice architectures.

7. Service Operation Design Principle

Critical services must not depend on non‑critical ones.

All calls should have timeout settings.

Call results are limited to success, failure, or unknown.

Prefer asynchronous calls when possible.

Service granularity should suit a team of 3‑8 developers.

Data‑service layer is often split first due to high reuse.

Avoid single points of failure.

Apply fast‑fail to prevent prolonged latency.

Special handling for high‑pressure call chains.

Avoid duplicate services across units.

Ensure backward compatibility or enforce upgrade controls.

Architecture must adapt to organizational changes.

Separate read/write services and core/non‑core services.

Consider security in service design.

Static resources can also be serviced separately.

Instrument outer systems for fine‑grained service management.

Encapsulate common business rules as services.

8. Service Constraint Principle

Higher layers may depend on lower layers, but not vice‑versa.

Cross‑level dependencies are allowed downward.

Same‑level calls must be unidirectional; cycles are prohibited.

Higher levels must not depend on lower levels.

Simplicity is paramount.

Critical services must not rely on non‑critical ones.

Distributed Runtime Mechanism

The middle platform adopts a microservice style; each business center is independently deployed, requiring a distributed runtime mechanism to ensure normal operation. Stateless microservices enable elastic scaling, gray releases, and high availability, but also introduce complexity that must be managed through configuration consistency, real‑time monitoring, service discovery, and fault localization.

1. Service Registration and Discovery

Instances register their IP, port, and name to a registry, which exposes health‑checked service metadata via APIs. Consumers retrieve instance information from the registry and invoke services accordingly, with load‑balancing across multiple instances.

2. Elastic Scaling

Probes monitor container health and automatically adjust instance counts: scaling out when CPU, latency, or load thresholds are exceeded, and scaling in when resources are underutilized.

3. Rate Limiting and Degradation

Systems detect traffic spikes and apply token‑bucket or fixed‑quota limits; degradation returns immediate failures or default responses when services are throttled.

4. Gray Release

Multiple versions run concurrently; traffic is split by weight, IP segment, or user tags, allowing safe rollout and rollback of new versions.

5. Message Queue Service

Message queues provide asynchronous communication, high availability through master‑slave clustering, reliable persistence via synchronous double‑write or asynchronous replication, and eventual consistency using half‑message techniques with idempotent consumers.

6. Distributed Transactions

Two‑phase commit (XA) coordinates multiple resource managers under a transaction manager, ensuring atomicity across services; cloud providers offer managed global transaction services such as Alibaba Cloud GTS for simpler integration.

Extension Point Mechanism

The platform offers configurable features and an extension‑point mechanism based on Java SPI, allowing new business logic to be added without modifying existing code when substantial differences arise.