0

Domain: Barbershop

Could someone help me to understand how to represent these related entities using the Aggregate pattern?

I have this hierarchy (in my mind)

ServiceGroup (Expected to contain ~50 services)
 - Service (Expected to contain ~30 specialists)
   - AssignedSpecialist
      - specialist_id
      - price
      - duration
    - AssignedSpecialist
      - specialist_id
      - price
      - duration
  ...
- Service
- Service
...
Legends:

ServiceGroup - is a container for related services
Service - is a container for assigned specialists to the service
AssignedSpecialist - contains price and duration related to the particular specialist (barber)

Rules:

  • ServiceGroup

    • Must not contain more than 30 services
    • Remove service group (when removed, all included services must be removed and assigned specialists unassigned)
    • Change name
    • Change description
  • Service

    • Change service group
    • Change name
    • Change description
    • Assign specialist
    • Unassign specialist
    • Remove service (when removed, unassign all specialists)
  • AssignedSpecialist

    • Change price
    • Change duration
    • Unassign

It seems like having a large ServiceGroup aggregate is too much. Every price change of the AssignedSpecialists will require updating other specialists and services, which can hurt performance.

Making those entities separate aggregates forces me to break consistency and move invariants to domain services.

Could you help me understand what cons are appropriate in this case?

1
  • If it were me, I'd make Service the aggregate root and let ServiceGroup simply be a property of a Service.
    – Dan Wilson
    Aug 16 at 15:13

0

Your Answer

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

Browse other questions tagged or ask your own question.