Best of Domain-Driven Design — April 2026

1. 1
   Article

   Milan Jovanović·5w

   Why I Switched to Primary Constructors for DI in C#

   C# 12 primary constructors can significantly reduce boilerplate in DI service classes by eliminating field declarations, constructor bodies, and assignments. The author shares their experience switching to primary constructors for ASP.NET Core services, explaining the key pitfall: parameters are captured as mutable variables, not readonly fields, meaning accidental reassignment compiles without warning. The recommended approach is to use primary constructors freely in DI service classes where accidental reassignment is unlikely, but fall back to traditional constructors for validation-heavy types, multiple constructor overloads, or classes with too many dependencies.

   51

   4
2. 2
   Article

   Architecture Weekly·5w

   Yoda Principle for better integrations

   The 'Yoda Principle' argues that API commands and integration messages should express clear business intentions (e.g., ReserveProducts) rather than vague verification actions (e.g., VerifyProductExists). Using prefixes like Verify/Validate/Check leads to query-like commands that obscure real business intent, create chatty communication patterns, and leave systems vulnerable to race conditions. Commands should declare what you want done, not ask whether something is possible, with the handling module responsible for enforcing its own business rules and returning success, failure, or timeout events.

   44

   3
3. 3
   Video

   Zoran Horvat·5w

   EF Core Is DDD (Here Is Why)

   EF Core natively supports Domain-Driven Design patterns without requiring custom wrappers. The post walks through configuring aggregates using EF Core's built-in configuration classes, achieving persistence ignorance by moving surrogate keys to shadow properties, implementing strongly-typed public IDs with value converters and alternate keys for cross-aggregate references, and applying CQRS where DbSets act as repositories, DbContext as unit of work, and LINQ to Entities as specifications. The conclusion is that wrapping EF Core to make it 'more DDD-like' is unnecessary since the implementation already exists.

   29
4. 4
   Video

   Zoran Horvat·4w

   Your DDD Abstractions Are a Waste of Code

   A pragmatic critique of over-engineered DDD abstractions around Entity Framework Core. Instead of building heavyweight wrapper classes for repository, unit of work, and specification patterns, the author advocates using thin interfaces that delegate directly to DbContext — treating DbSet as the repository, LINQ to Entities as the specification, and DbContext itself as the unit of work. The result is persistence-ignorant, testable application code with minimal boilerplate. For queries, named query classes in the infrastructure layer replace abstract specification hierarchies. The approach keeps DDD's intent (decoupling, clarity) while eliminating unnecessary layers.

   41

   2