title: The right way to implement associations in DDD?
body: <p>We are trying to adopt Domain-Driven Design in our project for the first time. The problem I have is with associations between entities. How do you do them right?</p>
  
  <p>Say, I've got entities <code>Employee</code> and <code>Contract</code>, a simple one-to-many association. How do I model it? </p>
  
  <p><strong>Option 1:</strong> Aggregate. </p>
  
  <p><strong>Problem:</strong> The problem here is that, if I understand it correctly, all entities in an aggregate must be loaded when an aggregate object is created. I can't lazy-load entities when they are needed because it would require referencing a repository from an entity, which apparently is bad. But fetching all of an employee's contracts from the database every time would be a big performance issue.</p>
  
  <p><strong>Option 2:</strong> Fetching an employee's contracts by using a repository (e.g. <code>ContractRepository.GetContractsForEmployee()</code>) and adding <code>EmployeeId</code> property to <code>Contract</code> class. </p>
  
  <p><strong>Problem:</strong> it makes hard to put any business logic into entities. I would like to have a method, say, <code>Employee.Dismiss()</code>, but it would also need to update the employee's contract. This means I would need to put this logic in a service. The problem is, I can't think of much logic operating only on an <code>Employee</code> and thus the model would become somewhat anemic, with most logic inside services.</p>
  
  <p>How do you deal with these issues in DDD?</p>