How to avoid having very large objects with Domain Driven Design

Question

We are following Domain Driven Design for the implementation of a large website.

However by putting the behaviour on the domain objects we are ending up with some ve

Answer 1

Although real humans have lots of responsibilities, you're heading towards the God object anti-pattern.

As others have hinted, you should extract those responsibilities into separate Repositories and/or Domain Services. E.g.:

SecurityService.Authenticate(credentials, customer)
OrderRepository.GetOrderHistoryFor(Customer)
RefundsService.StartRefundProcess(order)

Be specific with naming conventions (i.e. use OrderRepository or OrderService, instead of OrderManager)

You've run into this problem because of convenience. i.e. it's convenient to treat a WebsiteUser as an aggregate root, and to access everything through it.

If you place more emphasis on clarity instead of convenience, it should help separate these concerns. Unfortunately, it does mean that team members must now be aware of the new Services.

Another way to think of it: just as Entities shouldn't perform their own persistence (which is why we use Repositories), your WebsiteUser should not handle Refunds/Segmentation/etc.

Hope that helps!