Aggregates in DDD: when to use them for reads and when for writes in C# and .NET

The article explains the Aggregate concept in Domain-Driven Design using a food order example, where an Order root owns order items and extras that must stay consistent. It argues that write operations such as adding extras should go through the aggregate root, which enforces business rules like blocking changes once an order is completed. For reads, the author suggests separate endpoints or DTO projections that fetch only the data a screen needs, avoiding loading full object graphs. The piece concludes that aggregate boundaries are defined by consistency rules rather than by how many UI views exist. It also notes that read models can combine data across aggregates within the application's access limits.