I’m confused about the structure of the following aggregate in my design.
Should one root be for the whole aggregate graph or should multiple roots be in the same graph?
Id| Name | NumberOfAvailableRotations| IsActive 1| General Rule | 2 | true
Id| Name | NumberOfHours| NumberOfShortDays |WorkTimeRegulationId 1 | Winter | 8 | 1 | 1 2 | Summer | 6 | 0 | 1
Id| StartDate | EndDate | IsDeFacto |WorkTimeId 1 | 2018-10-1 | 2018-12-30 | 1 | 1
Note: I consider (StartDate&EndDate) as DateTimeRange(valueobject)
Now Should I consider the
WorktimeRegulation the root for the whole graph, so it controls both (
WorktimeRegulation(ROOT) | V WorkTime | V WorkTimeActivation
Or Should I have Two aggregates like this:
WorktimeRegulation(ROOT) | WorkTime(ROOT) | | | V | V WorkTime | WorkTimeActivation
So In the second solution I have two roots! But If I consider
WorkTime as a root It will be available to be used separately from the
WorktimeRegulation and I don’t want this because this will break the integrity of the first aggregate.
Based on the Comment :
Could you just explain the business problem this solves and what
invariants must be protected instead of the database structure
WorkTimeRegulationshould have at least one
WorkTimeto be valid. So in the creation of
WorkTimeRegulationI make sure to enforce this invariant.
- I need to check any conflicts between activated
WorkTimes, so after that I enforce specific activation based on the recent activation or
IsDeFactoenforced by the user
- What behaviors can be performed on WorkTime? So far I can see it can
Yes, In addition to updating the
WorkTime, It can be activated.
- In order to validate the activation do you need the entire
activation history or only the latest event?
Not the entire activation history, I could say the most recent single activation history.
Does the activation rules span multiple WorkTime (e.g. if one is
active then the other can’t be)?
WorktimeRegulationI mean If I have
WorkTimesthen there’s one and only one active
Worktimefor this regulation.
Can the name, numberOfHours, etc of activations be modified?
If You meant
Activationthen yes (Through this attribute the user can enforce specific activation if there was conflict between two activations of the same
WorktimeRegulation),and because the previous attributes in your question belong to
numberOfHourscan be modified.
Should modifying these details conflict with other business
operations (e.g. activating a WorkTime?
If You meant by
these detailsthe previous attributes,then the answer is no.
“if there was conflict between two activations of the same
WorktimeRegulation” Could you expand on what kind of conflicts could
occur? Shouldn’t the system prevent activation conflicts from
occuring? How does the activation process work exactly?
According to the business expert explanation: It might happen a conflict and the system should not prevent it but it alerts this conflict to the end user.
The activation performed like this:
The user selects a specific
WorkTimeRegulationto activate, Then the activation popup allowing the user to insert StartDate and expected EndDate, and when the user clicks activate, It should check for any conflict with the previous activation in the same
WorkTimeRegulationand alert the user if he wants the priority for the previous activation then He should use
IsDefactoto enforce one of them in the case of conflicts.
NOTE: The end user doesn’t know exactly the end date for activating worktime in advance, So he inserts expected end date, So the conflict may happen.
what would be the cost of having WorktimeRegulation point to a
non-existing WorkTime for a short period of time (e.g.
regulation.activateWorkTime(workTimeId) but then the activated work
item gets deleted)? Can WorkTime get deleted/archived?
WorktimeRegulationcan’t point to a non-existing
WorkTimethe work time can’t be deleted or archived if it activated once at least, Just activated and (deactivated when activate other work time in the same regulation)
Can WorkTime be associated to a different Regulation after it’s
Are you sure it doesn’t matter if for instance, name or
numberOfHours changes at the same time as someone attempts to
activate a WorkTime?
Now I get your question, The user can’t change WorkTime after the first activation.
I’m still not clear as to why conflicting activations could occur.
Why would you want to allow overlapping activation periods, but then
use a flag to specific which one to enforce. Seems easy enough to
prevent overlapping activation periods instead, no? Is it really
possible from the business perspective that two activation periods
overlap conceptually? Why do users even enter the startDate and
endDate manually? Couldn’t you just track the dates at which
activation/deactivation occurs in the system?
According to the business expert, The start date of the activation for a specific WorkTime is a decision taken from the company manager(not planned) to work with this
WorkTimeand after a time duration (can’t be predicted because It’s a decision) The company manager take a decision to switch to another WorkTime, So HR employee executes the decision by inserting a specific start date and inserts roughly end date, So the next activation may conflict with the most recent one.
What’s the actual business meaning of a WorkTime activation/deact?
During the year, The employees whom subject to a specific
WorkTimeschanged based on
the activation, I mean The
WorkTimemay be 8hours from Oct to Dec then switched to 6 hours(another
WorkTime) from Jan to Sep and so on It’s like a cycle.
Note: The decision provides for start date only (e.g Winter
WorkTimeStarts from date …)
and not specifying the end date! So it is inserted roughly and as a
result the start date for the next activation may conflict with the
end date for the previous one)