1

I have a design question in the "field" of CQRS / DDD.

I will not explain in depth the domain, but only what's needed.

It's a CONTACT domain, so it manages the contact informations of people and organisations.

A relation can exist between people and addresses. This relation exists in time so it can be active or inactive (has activeDate and inactiveDate). A relation can also be defined as the "preferred" one.

There are some ways a relation can be defined as the preferred one.

  1. It is the first active one.
  2. It has been defined as the preferred one explicitely.
  3. It is the next in line when another relation expires or is no longer the preferred one.

So the corresponding events :

  1. AddressLinkRegisteredEvent - depends on the active / inactive
  2. PreferredAddressLinkChanged
  3. AddressLinkUnregisteredEvent
  4. AddressLinkInfoChangedEvent - maybe the user set the Relationship as inactive

So for example the business rule : "There should be at most one preferred address at any time".

When the event Handler will receive the "AddressLinkRegisteredEvent ", how should it know that it should write this address as the preferred one, without duplicating the business rules ?

Or, when receiving the "PreferredAddressLinkChanged", how should it know to remove the "preferred" flag from the previous preferred address and apply it to the new one?

Thank you for your insights.

3
  • What makes you think business rules would be duplicated? Commented Sep 8, 2016 at 5:20
  • In the domain, I have to manage those business rules so that invariants are respected. In the read-model, I have to also manage those business rules to keep the read-model synchronized with the domain, to keep the projection accurate.
    – Ludovic C
    Commented Sep 8, 2016 at 11:52
  • @CandiedOrange I mean, the Read-Model event handlers would have to deduce that if they receive and event that states that a new address is defined as the preferred one, that it has to remove the "preferred" flag on the other address. That's a duplicated invariant (both in the domain and event-handlers that update the read model).
    – Ludovic C
    Commented Sep 8, 2016 at 12:10

1 Answer 1

1

So there must always be one prefered flag raised on addresses but there is no atomic way to change the flag without either having 0 or 2 flags raised for some small amount of time?

Solutions:

  • Create an atomic way
  • Rather than flag just keep an index into the list for the prefered address
  • Store the prefered address separately from the list of alternate addresses

Each has it's own drawbacks.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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