I have a DDD repository for Employee entity. Employee will have some borrowed equipment from his employer. Because there will be more employee related records like work reports, wage reports and Employee entity could become huge I'm thinking to exclude these related records actions out of Employee entity / repository.

I'm not sure but when I try to model actions in Employee entity I get something like these:

  • getBorrowedEquipments
  • returnEquipment
  • borrowEquipment
  • getWorkReports
  • getWorkReportDetail
  • etc

And these actions names / smell as a work with another entity and maybe it could be separated to the another repository. I think it's related to composition concept as is known in OOP.


What is proper entity / repository structure to work with related records to particular entity? E.g. for use case as "get all borrowed equipments for particular employee"? Or "return one equipment back to the employer"?

Thank you.


You should extract the equipment borrowing into another related Aggregate, having the same ID as the Employee. The reasons behind this would be one of the following:

  1. The equipment borrowing is from another bounded context that correspond to another domain/subdomain from the real world. Maybe another department is responsible for this?

  2. There is low cohesion between Employee's basic properties and the equipments that he is borrowing.

In either way, you would want to syncronized an EmployeeBorroedEquipments with an Employee in some situations. For example, when an Employee quits he will not be allowed anymore to borrow equipments. For this you could use a Saga/Process manager.

The same applies to the work reporting.

  • Thank you for your suggestions, I have no idea how do you suggest to design such aggregate and related repository. Do you suggest something like this, in repo: BorrowedItem borrow(EmployeeId id, Item itemToBorrow) and entity will hold all BorrowedItems with reference to employee id with ID value object? Thanks in advance for clarification / elaborating it in more detail. – Artegon Jul 23 '18 at 10:39
  • 1
    @Artegon you create another Aggregate, i.e. EmployeeBorrowedItems having the following properties: employeeId and the list of borrowed items as Value objects or nested entities – Constantin Galbenu Jul 23 '18 at 10:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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