Aw: Aggregate for transactional consistency

In a recent project I had actually quite the same problem to solve and I was also struggling a bit with how to apply DDD to such requirements. While I can not come up with a complete solution I'd like to share some loosely coupled thoughts which may be helpful for you.

- I first also approached the problem with quite a similar solution having some kind of grouping AR encapsulating all the items (versions of Articles in our scenario) - I discarded the approach rather quickly due to the size problem you also mention.

- One thing I was thinking about is if this kind of situation demands for different contexts - think of something like a Public context, a Authoring context and a Historical context. Don't know if this would match your domain - in our case the Public context was kind of a Marketplace where I think a separation from the Authoring context was applicable. The WorkflowGroup could be represented in all contexts and expose only that behaviour relevant for that context. However, I am very unsure about this - BC modelling is always quite hard imo.

- If you look at the Items you see that they actually behave quite differently in the different states - editable and publishable in 'Working' state, archivable in 'Published' state and immutable in the 'Archived' state. One approach might be to encapsulate all common Item properties like title, text, ... in a VO and use this within different aggregates PublishedItem, WorkingItem, ArchivedItem which encapsulate the different behaviours. This could help to relieve the WorkflowGroup a bit.

- The big WorkflowGroup AR can be shrinked a lot by looking closer at what is needed to enforce the invariants. You do not need all details of published and archived items to enforce the mentioned invariants imo. The WorkflowGroup AR would need to encapsulate state for all Items as well as the details of the one Working Item that can be edited. All published and archived items can be referenced by ID imo. State information would not be included in the Item here, Published and Archived Items would be (immutable) entities in their own right while the Working Item is part of the WorkflowGroup aggregate. The WorkflowGroup would still be the entry point for publishing and editing. In order to find the published item for a WorkflowGroup you would need to load the group first to find out the
ID of the published item. But imo you can have strong consistency here with regard to the invariants.

As I said - just some thoughts that hopefully inspire you a bit. I wasn't able to come up with a final solution in my project due to organizational reasons - actually this really bugs me and lead me to come back and think about this issue from time to time.

Regards

Gesendet: Dienstag, 11. Juni 2013 um 21:48 Uhr

Von: j88bradshaw88 <[email protected]>

An: [email protected]

Betreff: [domaindrivendesign] Aggregate for transactional consistency

I am developing a CMS type application and am looking to use some ddd tactical patterns. Here is the situation:

The application deals with the authoring and publishing of items.

Items are grouped together in a workflow group. Within that group, one item may be marked as 'Published', one item as 'Working' and any number as 'Archived'.

A item can only be edited when it is in the 'Working' state.

When a working item is published it replaces its corresponding published item (if there is one), which would be then marked as Archived.

If no draft exists, a new working version may be created by copying the published version or any of the archived versions.

The question is, following the guidance that Aggregates should encapsulate system invariants, should Workflow Group be an Aggregate root - encompassing all its items?

My worry is that this would make quite a large aggregate, and it would stop items being globally accessible (i.e. all interaction would have to go through the Workflow Group AR).

The alternative I see is to make Item an Aggregate Root, and then have a Domain Service deal with the transactions and invariants. For instance:

PublishWorkingItem(int itemId)

{

Item workingItem = itemRepo.GetWorkingItem(itemId);

Guid groupId = workingItem.GroupId;

Item publishedItem = itemRepo.GetPublishedItemForGroup(groupId);

if(publishedItem != null)

{

publisheditem.Archive();

}

workingItem.Publish();

}

To add to the complexity, there needs to be different types of Item(i.e. Artcile, etc.) so Item would be an abstract class that is derived from.

__._,_.___

Your email settings: Individual Email|Traditional

Change settings via the Web (Yahoo! ID required)

Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured

Visit Your Group |
Yahoo! Groups Terms of Use |
Unsubscribe

__,_._,___