Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
The Evolution of DDD and Common Mistakes: From the Blue Book to Dynamic Consistency Boundaries
DDD's most common mistake is skipping the strategic design left at the end of the Blue Book and taking only tactical words like entity, repository, and base class. A history from Evans's 2003 book to the DDD Reference, Vernon's aggregate rules, EventStorming, Team Topologies and Khononov, and the Dynamic Consistency Boundary that questions the aggregate; with an in-memory DCB example and a reading route after the series.
End to End: Refactoring Bookstore's Ordering Context from Anemic CRUD to a Rich Model
The safe way to move anemic CRUD code to a rich model is to pin current behavior with characterization tests first, then take the language, value object, aggregate boundary, invariant, and domain event steps as separate commits that each stay green. We transform Bookstore's Ordering in 11 commits and show refactoring toward deeper insight with a buy-3-pay-for-2 campaign, plus before/after metrics, all with real output.
Domain Events: Raise, Collect, and Dispatch on SaveChanges
An aggregate records what happened as a past-tense, immutable domain event in its own list; EF Core 10's SaveChangesInterceptor collects the events during SaveChanges, runs same-transaction handlers before the commit and side effects that leave the database after it. A mediator-free dispatcher, the nested SaveChanges and explicit transaction traps with real output, and how integration events and the outbox differ.
Domain Services, Application Services, and the Anemic Domain Model
Behavior goes first to the entity or value object that owns it; a stateless domain calculation that naturally belongs to none of them becomes a domain service, while loading, saving, and the transaction stay in a thin application service. We move Bookstore's copied shipping rule out of anemic services into Order and a ShippingFeeCalculator, with real output, and cover policies, factories, and the trap of injecting repositories into domain services.
Aggregate Design: Consistency Boundaries, Small Aggregates, and Referencing by Id
An aggregate is a consistency boundary that keeps true invariants consistent within a single transaction; the outside references only the root, and other aggregates are referenced only by id. We apply Vernon's four rules to Bookstore's Order and StockItem aggregates and work through a real EF Core run where a navigation property silently changes the catalog price, eventual consistency for stock, the 'whose job is it?' question and the Aggregate Design Canvas.
The Always-Valid Domain Model: Protecting Invariants with Constructors, Factories, and Guards
An always-valid domain model doesn't check invariants before saving, it makes violating them impossible: a private constructor, a static factory and guard clauses close every path to an invalid state. With Bookstore's Order we work through the at-least-one-item, 10-copies-per-book, single-currency and one-coupon rules, the limits of required/init and C# 14's field, the domain exception vs Result split, and the difference between input validation and invariants, with real output.
Entities and Value Objects: Identity, Equality, and Immutable Models with C# Records
An entity is defined by an identity that lasts through time, a value object only by its value: two Money values are the same if amount and currency match, two Orders only if their Ids do. We write Money, Isbn and strongly typed ids with C# records and readonly record structs, map them with the complex types EF Core 10 recommends over owned types, and show the collection-in-record, struct default and with pitfalls with real output.
Discovering the Domain with EventStorming: From Big Picture to Aggregates
EventStorming is a workshop format that brings domain experts and developers to a shared language by placing what happens in the domain on a timeline as orange, past-tense stickies. We take Bookstore's order flow through the Big Picture, Process Modeling and Software Design levels and turn the hot spots, pivotal events, policies and aggregate candidates from the wall into code.
Context Mapping: Anti-Corruption Layer, Open Host Service, and Relationships Between Bounded Contexts
A context map names the relationships between bounded contexts on both the technical and the organizational level: upstream/downstream, Partnership, Shared Kernel, Customer/Supplier, Conformist, Anti-Corruption Layer, Open Host Service, Published Language, Separate Ways, and Big Ball of Mud. Bookstore's context map, a tested ACL that translates the legacy carrier's SOAP/XML model into Shipping's, a versioned Published Language, and the trap of a Shared Kernel turning into Common.dll.
Bounded Context: Same Word, Different Meanings, and Model Boundaries
A bounded context is an explicitly drawn boundary within which a model and its language apply; because a "book" is a work on sale in Catalog, physical copies in Inventory, a purchased line in Ordering, and a box in Shipping, you need four models instead of one giant Book class. Evans's definition, CS0104 with .NET's Timers, how a bounded context differs from a subdomain and a microservice, sizing, a Bounded Context Canvas for Ordering, and one schema per context with EF Core.
Ubiquitous Language: Code That Speaks the Domain Expert's Language
Ubiquitous language is the one precise language that domain experts and developers speak inside a bounded context and that maps directly to class and method names: order.Cancel(reason) and RequestReturn instead of Status = 4. Separating ambiguous words (product, status, return versus refund), a glossary with a translation column for a team that speaks Turkish and writes English code, a reflection-based glossary check, and how HttpStatusCode followed RFC 9110's renaming.
What Is Domain-Driven Design? When It Pays Off and When It Doesn't
DDD accepts that complexity lives in the business rules rather than the technology and brings the model into code together with domain experts; it pays off in a core domain whose rules change often and is unnecessary for CRUD screens and short-lived MVPs. A campaign discount bug that shows the difference between a CRUD model and a domain model, strategic versus tactical design, eShop's Ordering.Domain, and the series roadmap.