A deep‑sea salvage fisherman sharing architecture insights, practical tips, and lessons learned.
This article explains why and how to separate a system into four DDD layers—User Interface, Application, Domain, and Infrastructure—illustrates the benefits of clear responsibilities, demonstrates dependency inversion and hexagonal architecture with concrete Spring Boot examples, and warns of common pitfalls.
The article explains why repository interfaces belong in the domain layer, implementations reside in the infrastructure layer, and factories should handle complex aggregate creation, illustrating how these patterns keep domain logic pure, enable dependency inversion, and simplify testing.
The article explains why cross‑aggregate business logic belongs in domain services, how domain events capture immutable business facts, and demonstrates practical Spring Boot implementations—including in‑process publishing, message‑queue integration, and the Outbox pattern—while highlighting pitfalls and verification techniques.
The article compares anemic and rich domain models using an order‑cancellation case, showing how setters and magic numbers in services lead to rule violations, and walks through a step‑by‑step refactor that moves business rules into the domain object for better encapsulation and consistency.
The article explains that an aggregate is defined by the business invariants that must stay strongly consistent, shows how the aggregate root protects those rules, and provides concrete design principles—ID references, single‑aggregate transactions, small boundaries, validation tests, and common pitfalls—illustrated with an order domain example.
Learn how to tell whether a domain concept is an Entity or a Value Object by asking if its identity matters or only its attributes, see concrete examples with Money, Address and Order, understand immutable design, proper equals/hashCode implementation, and validation through unit tests.
The article uses the ambiguous term “product” across product, inventory, order, and promotion teams to illustrate how bounded contexts and a ubiquitous language prevent model confusion, guide code organization, and enable safe evolution of a Spring Boot system.
This chapter explains how to strategically allocate modeling effort in a DDD project by distinguishing domains, subdomains, core, supporting, and generic subdomains, using the “Preferred Store” case to illustrate which areas merit detailed modeling and which can remain simple, ultimately guiding resource focus and decision‑making.
The article shows how a typical three‑layer OrderService accumulates scattered business rules, mixes technical details with domain logic, lacks clear boundaries, and diverges from business language, then explains how Domain‑Driven Design reorganizes code around aggregates and bounded contexts to solve these problems while outlining when DDD is unnecessary.
This article provides an in‑depth guide to Redis’s advanced capabilities, covering how to use pipeline for batch commands, transactions for ordered execution, Lua scripts for atomic logic, distributed locks with proper token handling, reliable messaging with streams, and specialized data structures such as BitMap, HyperLogLog, Bloom Filter and GEO for efficient large‑scale scenarios.
