I'm trying to apply DDD principles to an application that has a REST API in front and is backed by an SQL storage. Here's the entity structure I have come up with so far: Client: 1 ---- * Contract: 1 ----- * Contract-AddOn: 1 ----- * Feature The REST endpoints will basically represent the same structure. From /api/clients up to /api/clients/:clientId/contracts/:contractsId/addons/:addonId/features/:featureId I'll also have some business rules like: - A client can have only one active contract - A contract's addon cannot start or end outside the start-end period of the contract - .... With these 2 rules in mind it sounds to me like the Client should ensure that there's no more than one active contract => Client should be aggregate of Contracts. And then addon fields are restricted by Contract fields => Addons are entities in a Contract aggregate. So it seems like everything should go under Contract, but this feels clumsy. And then comes the REST layer which should access the Client aggregate and get the Contract for a client, get its addons to remove a feature from an addon. I guess I'm missing something in that model. I was considering if the two mentioned business rules are not just policies, but I can't quite grasp the difference between the two and which is used when. What would be another way to model such relation ship? Or maybe DDD is just too much for a simple model as this one?