The problem of loading extra data when using the DDD approach

[EXREGISTR]

What problem are you trying to solve?

When using the Domain Driven Design approach, entities are known to be the center of architecture, so business logic is centered in them. When working with the entity framework core, there is a problem that if we want to work with the methods of an entity, we need to load it completely, which is often completely unnecessary. Of course, the option of using projections is not suitable, because then we lose the opportunity to work with the very methods of the entity. In other words, there is no such method that would allow you to explicitly define the necessary properties for loading. There is a similar behavior for navigation properties, but there is no such thing for regular properties.

Describe the solution you'd like

Add a method to DbSet/IQuerable that will allow you to determine the data to query, but at the same time map the result to the domain entity so that it can also be correctly tracked by ChangeTracker. To do this, you will always need to upload IDs and foreign keys. And make a global setting so that only identifiers and foreign keys can be loaded by default, and the client code itself will specify which properties to load.

Example:

public class Order {
         private List<OrderItem> orderItems;
  
         public Guid Id { get private set } 
         public DateOnly CreatedAt { get private set } 
         .... 
         public OrderStatus Status { get private set } 
      
         private Order() {

         } 

         public static Order Create() {... } 
   
         public void UpdateStatus(OrderStatus status) {
                 if (Status == status) return;
         // something business logic and creation domain event
         } 
}

considering that we have enabled this global setting that disables loading all properties automatically:

Let's say the task is to implement an order status update:

Order order = await dbContext.Orders.IncludeProperty(x => x.Status).FirstOrDefaultAsync(x => x.Id == id);

and in this case, ef core sends a request to the database to get the Id and Status (Id, again, for the correct operation of ChangeTracker, I think based on the configurations, you can understand which properties to load behind the scenes), and skip the rest of the properties. in other words, the query will look as if we made a projection, only in the end we map it to the domain entity, and not to the DTO.

and after:

order.UpdateStatus(newStatus);
await dbContext.SaveChangesAsync();