Archives

When first encountering DDD, the terminology appears first. Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event, Bounded Context, Context Map. If CQRS, Event Sourcing, Hexagonal Architecture, and Microservice follow, DDD feels like a huge technical system.

DDD is a powerful approach, but it is not needed for every problem. It can greatly help complex domains, but applying it excessively to a simple CRUD system can only increase cost.

As a system grows, we start wanting to split services. It feels like creating independent services for orders, payments, members, notifications, and settlement will make things cleaner. It seems each team can own its service, deploy independently, and isolate failures.

When studying DDD, we see many clean examples. Domain objects are clear, layers are separated, and Aggregate boundaries are well defined. But real systems are often not like that.

Tests are usually seen as tools for preventing bugs. That is true. Tests check whether code behaves as expected and help prevent changes from breaking existing behavior.

When talking about DDD, microservices often appear together. The picture of splitting Bounded Contexts, making each context a service, and giving each independent deployment and an independent database is attractive.

After learning Domain Event, we naturally encounter Event Sourcing. If we express things that happened in the domain as events, storing events instead of state may look better.

When studying DDD, we often encounter the word CQRS. So it is easy to think that proper DDD requires CQRS, and that CQRS requires Event Sourcing.

Consistency is important in software. It is a problem if an order is created without payment information, if a subscription is renewed but access entitlements are not granted, or if a refund is completed but the settlement amount remains unchanged.

When talking about DDD in a Java and Spring environment, JPA almost inevitably comes up. The word Entity overlaps. JPA has Entity, and DDD has Entity. So many teams naturally use JPA Entities as their domain models.

Layered Architecture is an important starting point for protecting the domain model. But in real code, even when layers appear to flow in one direction, the domain is often still strongly tied to frameworks or databases.

When we try to implement DDD, architecture soon enters the conversation. Names such as Presentation Layer, Application Layer, Domain Layer, and Infrastructure Layer appear. We split packages, decide dependency direction, and separate responsibilities by layer.

Domain logic starts as small conditionals. If it is in a certain state, do not process it. If a certain date has passed, expire it. If it is a certain plan, do not discount it. At first, a few if statements are enough.

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.

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.

One of the most confusing names when applying DDD is Service. Application Service, Domain Service, and Infrastructure Service all have the word Service. So over time, all logic gathers in SomethingService.

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.

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.

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.

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.

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.

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.

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.

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.

A domain model is not made only of state. Things keep happening in the domain. Orders are placed, payments are completed, shipments are requested, subscriptions are renewed, refunds are approved, and entitlements expire.

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.

If asked to choose just one of the most important concepts in DDD, many people would say Bounded Context. At the same time, it is also one of the most misunderstood concepts.

Ubiquitous Language is one of the most important concepts in DDD, and also one of the easiest to treat lightly. Many teams understand Ubiquitous Language as little more than "creating a glossary." Of course, organizing terms is a good start. But Ubiquitous Language is much deeper than a glossary.

To understand DDD, we first need to rethink the word "model." Many people think of a model as something that copies reality as accurately as possible. There is a member in reality, so we create Member. There is an order, so we create Order. There is a payment, so we create Payment. We try to include every attribute that exists in reality.

When you first study DDD, technical terms naturally stand out first. Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event. Go a little further and terms like Layered Architecture, Hexagonal Architecture, CQRS, and Event Sourcing follow.