Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
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.
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.
Sharing Across Slices: Duplication or Abstraction, and Where Does Domain Logic Go?
Across slices you share the domain model, cross-cutting concerns, and infrastructure; you don't share request/response types, queries, or workflows, and invariants move into the entity without waiting for a second copy. With real output we see a rule placed on a request allow a 7-copy order and a slice calling another slice save an order whose payment was declined, then prevent that with an ArchUnitNET slice test.
Onion Architecture: Domain Model at the Center, Infrastructure on the Outer Ring
Onion Architecture (Palermo, 2008) builds the application around an independent domain model: inner rings define interfaces, outer rings implement them, all coupling points toward the center, and the core can be compiled and run without infrastructure. We place Bookstore's ordering code into Domain Model, Domain Services and Application Services rings and show how it differs from layered and Hexagonal, how rings relate to projects, and the ASP.NET Core Identity example.
From Requirements to Diagrams: Which Question Does Each Diagram Answer?
Every diagram answers one question: use cases answer who does what, class diagrams which concepts exist, sequence diagrams who calls whom, and state machines which states an object goes through. The requirements of the HR Portal Leave Request module, extracting candidate classes, use cases and guards from nouns, verbs and conditions, choosing the level of detail by audience, and the map of the series.