Repository Pattern – How to Avoid Code Duplication for Shared Entities

This is a common issue when implementing aggregates. It usually gives rise to separating aggregate state onto a another object. That object can be a pure data bucket with public getters/setters for convenience. Outside callers could be aware of the aggregate's state class, but it remains private to the aggregate (as a private field, for instance). The repository could directly load aggregate's state, which can be passed as a single object to the aggregate's constructor.

You would have:

public CustomerState
{
    public Guid Id { get; set; }
    public string ShortName { get; set; }
    public string LegalName { get; set; }
    public TaxCode TaxCode { get; set; }
    public ContactInfo PrimaryContact { get; set; }
    public List<Requisitions> Requisitions { get; set; }
}

public Customer
{
    private readonly CustomerState _state;
    private readonly IDomainEvents _events;

    public Customer(CustomerState state, IDomainEvents events) 
    {
        _state = state;
        _events = events;
    }
}

...

public Requisition OpenRequisition(RequisitionDefinition definition, User requestedBy) 
{
    Requisition req = ... // create the new requisition somehow
    _state.Requisitions.Add(req);
    _events.Invoke(new RequisitionCreatedEvent(this, req));

    return req;
}

Notice that I placed IDomainEvents in the aggregate instead of the state class, because it has some behavior (likely dispatching). For your state object, you only want pure data.

In a very surface way, this organizationally resembles an Anemic Domain Model because the state is separated, and the aggregate essentially just contains methods, similar to a Facade pattern. But the difference being that an anemic domain allows the user to directly manipulate state and run a Transaction Script on their manipulations. But with this, user is not allowed to directly manipulate state... we retain control of validated state changes through domain methods, but add easier loading (and saving).

Now, separating the state in this way does present it's own challenges. Usually naming confusion is one initially. You probably don't want to name your data table CustomerState (and it's probably already named Customer). But naming the table Customer will result in confusion when the aggregate of the same name is structurally dissimilar. If you're up for some reorganization, you might consider naming your aggregate Sales or Ordering or the like (based on what area it deals with) and keep the customer's state named as Customer. You might find that leads to better organizational clarity for your use cases anyway.

I don't use Active Record in my projects as this pattern is forcing me to break my golden DDD rule: keep the aggregates pure, side-effect free.

If you do not split the Read from the Write, then you have a mixed aggregate. You need to be able to command it and query it. The problem is not querying a single aggregate, you can easily do that, after it is loaded from the repository, the problem is finding, filtering, browsing a list of aggregates because it forces you to break the aggregate encapsulation by depending on its internal structure. You need to know its structure in order to apply filters based on properties values. Every time you modify a property on the aggregate you need to adapt the filtering too.

If you split the Read from the Write (i.e. using CQRS and Event sourcing), then you can do all of the above without breaking aggregate encapsulation because you will not query the aggregate, you will query a special designated read-model, without breaking its encapsulation (because it applies its own filters on its own fields).

So, using Event sourcing helps a lot regarding your problem.

Of course, there are other problems that come with Event sourcing.