Master High Cohesion & Low Coupling: Microservice Architecture Patterns and DDD Guide

Microservice Architecture Models

In distributed architectures, monolithic applications are split into multiple microservices; to ensure single responsibility and proper decomposition, the principle of "high cohesion, low coupling" is essential.

High cohesion means grouping related behaviors together and keeping unrelated ones elsewhere, so modifications are made in one place. Low coupling ensures that changing one service does not require changes in another, and a loosely coupled service knows as little as possible about its collaborators.

Clean Architecture (Onion Architecture)

Clean Architecture uses concentric circles to represent different parts of an application, from the inside out: domain model, domain services, application services, and the outermost layer for easily changeable concerns such as UI and infrastructure. The core principle is the Dependency Rule: inner layers must not depend on outer layers, and outer layers can only depend inward.

Key layers:

Entities : core business logic and rules, can be objects with methods or data structures with functions.

Use Cases : orchestrate user‑driven services, contain application‑specific rules, and implement all system use cases.

Interface Adapters : translate data between use cases/entities and external services.

Frameworks and Drivers : implement UI, tools, and frameworks.

Hexagonal Architecture (Ports & Adapters)

Hexagonal Architecture treats the application as a set of ports that interact with the outside world via adapters. Business logic (application and domain layers) is isolated from external resources (apps, web, databases) and communicates only through adapters, enabling true front‑back separation.

CQRS (Command‑Query Responsibility Segregation)

CQRS separates reads and writes to improve query performance and achieve read/write decoupling. Combined with DDD, it allows independent modeling of read and write sides. The query model is a denormalized view used only for display, while the command model executes domain behavior and notifies the query model, often via publish‑subscribe messaging.

Domain‑Driven Design Layered Architecture

Layered architecture enforces that each layer only depends on the layer directly below it. Benefits include clear structure, easier upgrades, and reduced impact of changes. Layers include:

Presentation Layer : UI and user interaction.

Application Layer : thin coordination layer that composes services, handles transactions, security, and forwards results.

Domain Layer : core business logic, aggregates, entities, domain services; remains pure and independent of infrastructure.

Infrastructure Layer : provides technical capabilities (databases, caches) via dependency inversion.

Keeping the domain layer pure and avoiding business logic leakage into other layers preserves low coupling and high cohesion.

Architecture Model Comparison and Analysis

Clean, Hexagonal, and DDD layered architectures differ in presentation but share the same high‑cohesion, low‑coupling philosophy, aligning perfectly with microservice design principles.

Designing Mid‑Platform and Microservices

Mid‑platform (or "middle platform") focuses on shared business capabilities, providing reusable services to front‑ends via APIs. The key is to keep domain logic pure, avoid polluting the domain layer with unrelated concerns, and decide service boundaries based on business context and team capabilities.

Typical scenarios:

Single‑application projects : follow the layered model; core domain logic resides in the domain layer, service composition in the application layer, and expose APIs via a gateway.

Enterprise‑level multi‑mid‑platform projects : multiple mid‑platforms expose APIs through a gateway; core domain services may be deployed as independent microservices or combined based on bounded contexts.

DDD‑Based Microservice Design Method

DDD consists of strategic design (domain modeling, service map) and tactical design (aggregates, entities, value objects, services). The process aligns business models, system models, architecture models, and code models.

Key stages:

Product Vision : define top‑level value, target users, and differentiation.

Scenario Analysis : identify core user scenarios and classify them.

Domain Modeling : use event‑storming to create aggregates and bounded‑context maps.

Service Map : define service granularity, boundaries, and integration based on business, performance, and organizational factors.

Microservice Boundary Design

Logical boundaries (bounded contexts, aggregates) guide microservice boundaries (physical deployment). Logical boundaries can be finer than physical ones, but over‑splitting leads to operational complexity.

Microservice Design and Splitting

Splitting methods include:

Strangler Fig Pattern : gradually replace legacy functionality with new services while keeping loose coupling.

Refactor‑in‑Place Pattern : isolate and rebuild problematic parts within the existing system, suitable for low‑change legacy systems.

Splitting principles emphasize high cohesion, low coupling, business domain alignment, change frequency, performance hotspots, team structure, package size, and technology heterogeneity.

Distributed Architecture Design Concerns

Key topics:

Data : choose appropriate distributed databases (integrated transaction‑type, middleware‑based, or sharding libraries), design sharding keys (customer‑centric or region‑centric), and handle caching for hot data.

Cross‑Database Queries : use global data views, data replicas, or small‑table broadcast to avoid expensive joins.

Data Redundancy : duplicate critical entities to reduce cross‑service calls.

Data Migration : plan migration strategies, possibly using data routing and unified views to avoid full migration.

Asynchronous vs Synchronous : employ event‑driven messaging for async workloads and near‑real‑time read/write separation.

Mid‑Platform & Microservice Boundaries : leverage DDD‑driven logical boundaries to simplify future recomposition.

Front‑Mid‑Back Collaboration : adopt micro‑frontend approaches, load data on demand, and use CDN for static assets.

Disaster Recovery & Multi‑Active : design for multi‑data‑center deployment, consistent configuration, and automated failover.

Avoid Over‑Splitting : control service granularity and limit distributed transactions to keep maintenance costs low.

In summary, applying DDD principles and disciplined layering yields clear boundaries, maintainable code, and scalable microservice systems.

Source: https://www.infoq.cn/article/7QgXyp4Jh3-5Pk6LydWw