I'm struggling with this problem for a long time now.

Lets say that I'm trying to model some business that has Customers, Companies, Contracts, Invoices etc. All of them looks like good candidate for aggregate root for me. The problem is that, lets say Contract would have a huge list of fields, and most of them would be required. So most of the time I end up with big aggregate root (a lot of data, some logic and invariants) with huge constructors. Even though I will break that into value objects its just minimizing a damage (instead of 20 i have 7 arguments) and most of the time those value objects are super artificial, does not event make much sense business vise, they are just some kind of data containers.

Second problem is updating this data. Should I add single method to update that, lets say UpdateAllThisJunkData(,,,,,,) or write one method for each ?

I also feel that aggregates like this are more CRUD kind and don't have much to do with DDD, but I also believe that we need to persist data somehow in the system even though its not using it to process any logic, just for historical and display purpose (user can make decisions base those values). Should I let say move that kind of data to different AR or VO ie. ContractData ?

There is also option that I'm paranoid and all is fine with my AR ;)

I would appreciate any thoughts


1 Answer 1


Not all data is required for every bounded context

While a Contract might indeed have a large number of fields, not every field will be relevant for every bounded context. For example, if you have an Invoice for a Customer that was created as part of a Contract it is very likely that there is information for the Contract that is not relevant for invoicing. Hence, you would have a bounded context where an Invoice has a reference back to a Contract, but where there are very few fields on the Contract because the process of invoicing has no need for this information.

If you feel like the Contract is more like a data container, I'm pretty sure this is the case. There is a bounded context where you need 20 or so fields to be entered so you have the data, but other places in your application will very likely not need these fields.

'Required' is relative

It's very easy to say that a Contract cannot exist without a huge list of fields, but are you SURE that it can't? It might not be valid to perform a certain action on a Contract if some fields are missing, but that does not mean that they have to be present when you create a contract.

Think of it this way: while you order something from an e-commerce website you might be filling out your order in several distinct steps, going through a number of screens to enter the products, shipping information, payment information, etc... The order is saved in between steps, even though it is lacking in the needed information to fullfill the order! The only difference is that before an order can be shipped it needs that information. It does not mean that it cannot be created.

  • In other words, there are different "levels of detail" for contracts. Possibly the huge monolithic notion of "contract" can be split to parts: essential data and various pieces of optional data. Optional data per se don't make so much sense, but it's OK. This solves the problem of huge DB records and huge constructors.
    – 9000
    Nov 6, 2015 at 14:55
  • 1
    Bounded Contexts, essentially, yes. For a support engineer a contract might be mostly about uptime guarantees and service levels, for a lawyer it might be about penalty clauses and the likes.
    – JDT
    Nov 6, 2015 at 15:12
  • Thanks for this clarification - this is just what I needed to be sure that I failed in basic design :)
    – mgibas
    Nov 8, 2015 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.