Core Concepts of Microservice Architecture and Its Relationship with Domain‑Driven Design

Microservice architecture has become popular, and this article compares it with traditional SOA, highlighting both similarities (registry, transaction consistency, gateway, logging) and key differences such as service granularity and the importance of proper service boundaries.

It emphasizes that the essence of microservices lies in how services are split; overly coarse‑grained services or “pseudo‑microservices” that only separate business logic without separating data storage lead to coupling and performance issues.

Domain‑Driven Design (DDD) is presented as a practical method for service decomposition, using concepts such as Bounded Context to map business domains to independent services.

The article then contrasts the “transaction script” (anemic model) approach with the “rich model” (active‑record) approach. A Java class example and accompanying SQL pseudo‑code illustrate the anemic style, where business logic is expressed as raw SQL statements:

public class Stock { private String spuId; private String skuId; private int stockNum; private int orderStockNum; } count = select stocknum from stock where spuId=xx and skuid=xx; if (count > num) { update stock set stocknum=stocknum-num, orderstocknum=orderstocknum+num where skuId=xx and spuId=xx; } else { //库存不足，扣减失败 } insert stock_log set xx=xx, date= new Date();

In the rich model, business behavior is encapsulated within domain objects (e.g., an Inventory entity) and invoked through application services, reducing coupling and aligning with OOP principles, though it introduces concurrency challenges that can be mitigated with event‑driven architectures.

Overall, the piece argues that successful microservice adoption requires careful boundary definition, DDD‑guided decomposition, and a shift from procedural scripts to domain‑centric rich models.