Designing a Scalable Business Middle Platform: Modeling, Service Principles, and Distributed Operations

From business to middle platform, an abstract modeling process is required, consisting of two stages: level‑0 abstract central modeling and level‑1 abstract component modeling, both using entity abstraction.

First, gather enterprise functional requirements (e.g., a beverage company's requirement table) and identify the business objects or entities for each requirement, distinguishing static (business) entities from process entities. Similar entities are grouped, and domain capabilities—operations or commands applied to entities—are defined.

Next, based on capability themes and entity relationships, define domain areas (business domains) with clear naming to avoid ambiguity, producing an abstraction table.

After dividing multiple domain areas, architects combine them into centers, balancing entity aggregation, responsibilities, granularity, and independent operation. The resulting center plan is illustrated in the figures.

Eight Design Principles of a Business Middle Platform

1. Service Loose Coupling

Interface‑based implementation so consumers do not depend on specific service implementations.

Asynchronous event decoupling via message queues.

Provider location decoupling using a service registry.

Version loose coupling with backward‑compatible contracts.

2. Service Dependency Principle

Valuable domain models aligned with business goals.

Minimal service dependencies: high cohesion, low coupling, clear capabilities and interfaces.

Hierarchical capability entities separating interfaces from capabilities.

Delay technical component dependencies (bundled vs. delayed binding).

3. Service Design Principle

Optimize remote calls (choose sync or async based on scenario).

Eliminate redundant data in interface entities.

Design coarse‑grained service interfaces matching a use case.

Create generic service interfaces for broad compatibility.

Isolate internal changes from clients.

Define service contracts first.

Ensure backward compatibility of service interfaces.

4. Service Naming Principle

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

5. Service Granularity Principle

Services should be cohesive and complete, capable of independently fulfilling a responsibility.

6. Stateless Service Principle

Stateless microservices enable scalability and high availability.

7. Service Operation Design Principle

Important services must not depend on non‑important ones.

Set timeouts for all service calls.

Call results are success, failure, or unknown.

Prefer asynchronous calls when possible.

Maintain reasonable team size per service (3‑8 developers).

Start splitting from data service layer.

Avoid single points of failure.

Apply fast‑fail principle to prevent long‑running failures.

Handle high‑pressure call chains with shortcuts or pre‑warming.

Prevent duplicate services across units.

Ensure backward compatibility or enforce upgrade controls.

Align organizational structure with service architecture.

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

Consider security in service design.

Separate static and dynamic resources.

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 upward.

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

Higher levels must not depend on lower levels.

Simplicity is preferred.

Important services cannot depend on non‑important ones.

Distributed Runtime Mechanisms

The middle platform adopts a microservice style, with each business center deployed independently, requiring a distributed runtime to ensure normal operation.

1. Service Registration and Discovery

Instances register their IP, port, and name to a registry, which exposes health‑checked service information via APIs; consumers retrieve instance data and invoke services, with load‑balancing across multiple instances.

2. Elastic Scaling

Service probes monitor container health and automatically adjust instance counts—scaling out when load, CPU, or response time spikes, and scaling in when resources are underutilized.

3. Rate Limiting and Degradation

Rate limiting controls request bursts using token‑bucket algorithms; degradation returns immediate failures or default responses when a service is throttled, with configurable rules.

4. Gray Release

Supports parallel deployment of multiple versions, allowing traffic splitting by weight, IP segment, or user tags, and enabling smooth transition from old to new versions.

5. Message Queue Service

Provides asynchronous communication, high availability through clustered masters and replicas, and high reliability via persistence, retry mechanisms, and eventual consistency using half‑message techniques.

6. Distributed Transactions

Implements two‑phase commit (X/Open XA) with transaction managers coordinating global and branch transactions; cloud providers offer global transaction services such as Alibaba Cloud GTS for simpler scenarios.

Extension Point Mechanism

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