replicator.org ... continuous garbage collection

With BrainSharper getting mature, the domain model is starting to show dependencies among the different objects. For example, a node can connect to other nodes, and before a node is deleted, all its connections need to be deleted.

The following ideas came to my mind:

• Enforcing constraints at the domain model.
  This sounds like a good idea, but at the time the primary event is integrated into the domain model, it is too late to do anything else, otherwise the compensating change sets would miss the constraint induced changes. The compensating change set needs to be created before the domain layer is modified.
• Enforcing constraints at the time the change set is created.
  To keep the domain model consistent, dependencies need to be processed before the primary, destructive event is processed. I.e. The connections shall be deleted before the node is. To create these events, the current, unaltered domain model can be used. Then these events need to be placed before the node deletion inside the same change set. This change set does not conflict internally and will generate a matching compensating change set.

Obviously, the second solution seems to be the only way to move forward.

Programming a solution to this specific problem is not a big task, but what about dependencies in general, what if they get more complex? For example, BrainSharper needs to support labels at the connectors and adding connections to the labels may also be allowed. And what if multiple nodes were deleted at once?

Consequently, there is a more generic, recursive dependency problem to solve. I guess this cries for a small DSL, which describes the dependencies among the domain model and specifies the events that need to be created to enforce the constraints.

Update: Instead of a DSL, I’ve implemented a dependency resolution algorithm which recognizes all destructive events in a change set and prefixes them with the destructive events of the dependent objects. The destructions had to be topologically sorted to remove duplicates and keep the order consistent. This ensures that the (re)creation events of the compensating change set were ordered properly. Not a perfect solution yet, but generic enough to be extended with a few lines of code.