Tag: Tactical Design
All the articles with the tag "Tactical Design".
-
[DDD Intro #17] Factory: Creation also contains domain knowledge
Object creation is often treated as a simple technical problem. It is easy to think that we only need to call a constructor, pass the needed values, and fill fields. But in a domain model, creation can also be an important behavior.
-
[DDD Intro #16] Domain Service: Domain logic that is hard to force into an object
When studying DDD, we often hear that "domain logic should be inside domain objects." This is important. If domain rules scatter into Application Services or Controllers, the model becomes anemic.
-
[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 #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 #5] Aggregate: The boundary of consistency
Among DDD's tactical patterns, Aggregate is one of the most important and most misunderstood concepts. Entity and Value Object are relatively intuitive. Aggregate feels vague when we first encounter it.