Posts
All the articles I've posted.
-
[DDD Intro #14] Repository: Treating it like a domain collection, not a DAO
Repository is a frequently misunderstood pattern in DDD. In many codebases, Repository is used almost like a DAO. An object that reads data from a database, updates specific columns, and executes necessary queries gets the name Repository.
-
[DDD Intro #13] What it means to put behavior into domain objects
Even when a team says it applies DDD, domain objects often do almost nothing in real code. Class names look domain-like, such as Subscription, Order, and Payment, but inside they only have fields, getters, and setters. Most important rules live in service classes such as SubscriptionService, OrderService, and PaymentService.
-
[DDD Intro #12] Entity: A domain object with identity and lifecycle
A Value Object is identified by value. 10,000 won is 10,000 won, and a period with the same start date and end date is the same period. What matters is the value itself.
-
[DDD Intro #11] Value Object: Expressing domain concepts instead of primitive values
When thinking of DDD's tactical patterns, many people start with Entity. Objects with identifiers, lifecycles, and state changes are certainly important. But in real code, the smallest and clearest starting point for revealing domain meaning is often a Value Object.
-
[DDD Intro #10] Anti-Corruption Layer: Protecting my model from external models
Creating a good domain model is hard. We need to talk with domain experts, refine Ubiquitous Language, split Bounded Contexts, and think about Aggregate boundaries. But even a model created with difficulty can easily break down.
-
[DDD Intro #9] Context Map: Boundaries do not exist alone
Once we understand Bounded Context, we let go of the desire to merge models into one. We accept that the same word can have different meanings depending on context, and that several consistent models can be better than one giant model.
-
[DDD Intro #8] Core Domain: Do not spend the same care everywhere
When studying DDD, it is tempting to apply good design everywhere. We create Entities, Value Objects, split Aggregates, and set up Repositories and Domain Services. We publish Domain Events and cleanly separate layers.
-
[DDD Intro #7] Why DDD fails
After studying DDD, it feels like design should get better. Once we learn concepts such as Entity, Value Object, Aggregate, Repository, and Domain Event, it feels like complex business logic can be organized cleanly.