Tag: DDD
All the articles with the tag "DDD".
-
[DDD Intro #22] Transactions and consistency: What must be protected at once?
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.
-
[DDD Intro #21] ORM and DDD: Is a JPA Entity a domain model?
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.
-
[DDD Intro #20] Hexagonal Architecture: A structure that places the domain at the center
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.
-
[DDD Intro #19] Layered Architecture: Protecting the domain layer
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.
-
[DDD Intro #18] Specification and Policy: Modeling conditions and policies
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.
-
[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 #15] Application Service: The layer that coordinates use cases
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.