DDD: Aggregate root too many lines of code

Question

I am following the DDD principles and have these Aggregate root classes. The problem is that after some time my class contains 1400 lines of code which makes development experience a little bit worse.

Is there any recommended way by DDD how can I split this AggregateRoot class into few classes?

I know, it can be said that I should reduce my bounded context but that's not the case. All the methods and fields in class belongs where it should belong just as every VO is created by the root method it contains quite many different public and private methods.

Answer 1

Is there any recommended way by DDD how can I split this AggregateRoot class into few classes?

There are at least two different approaches that may help.

One possibility is to review your model, and think about whether your aggregate is really multiple domain entities acting in a coordinated fashion. Your "root" entity code may be reduced by delegating responsibilities to other subordinate entities.

Another possibility is to delegate your computations. For example, if we have complicated computations using values, it can make sense to move that computation of the entity and into the value itself (or possibly into a "domain service"), or just into a function that lives "somewhere else".

In the Cargo example developed by Citerus, Cargois an entity that plays the role of an "aggregate root". A lot of the important domain information that supports Cargo's responsibilities is actually managed by a Delivery value object, and that's where the code that computes those changes lives.

In all, the Cargo aggregate is implemented as a single entity, and eight different values of varying size. Delivery is by far the largest; measured in lines of code, it is larger than the Cargo entity.

which makes development experience a little bit worse.

Yes.

Keep in mind that the real goal here is to create a design that is easy to adapt; nobody is awarding prizes for "Certified 100% DDD compliant". If the patterns described by Eric Evans aren't making things better, then don't use those patterns.

Answer 2

The first thing to do is verify that business logic hasn't leaked into your repository. Any code that isn't talking to a data source or mapping data to a return object doesn't belong in a root. Another red flag is boolean values getting set in the root that aren't directly from the underlying data. Setting a name property to the combination of first and last names is the most complex thing that should exist in your root from a logic perspective.

The next thing would be to analyze the public interface, the thing to look for is that all return types are objects related to your entity. Primitive return types are a code smell here, that usually means your domain is anemic and these methods are thinly veiled business logic. Sometimes you may need a simple get username or account balance type method that just returns a string or number, but those are exceptional cases. More than two primitive returns in an aggregate is a good sign something is wrong, and your objects don't know enough to do anything. Additional returning Foos and Bars from your aggregate is another sign that an aggregate is doing too much and you really do have room to further reduce your context.

Finally if you still have a massive class that you desperately want to shrink the next step would be following a CQRS pattern. This means physically separating your root into read and write versions. This requires a lot of discipline for developers to maintain that separation, because if it gets broken you end up with a far bigger mess than just a big class. This isn't something that should be done first to make an aggregate smaller, because queries with side effects or updates doing business logic will instantly make spaghetti code.