Re: Aggregate for transactional consistency

It never says so in the DDD book, but your data reads and writes should be
bite sized chunks. Not too big, and not too small.

If you go back to a conventional programming mindset for a minute, you
would do validation and aggregation in screen chunks. I tend to create
manifests to make screens and use CQRS for commands/reads as separate items
but the manifest almost always includes a chunk that anticipates the result
for an update command.

This is the backdrop that influences my domain decisions. The question I
want to always answer in roughly the right way is what validation
requirements are there for all the commands that I want to do against this
entity (using the term loosely here). When I know roughly what that is
going to be like, I have a better idea what to do with aggregates, roots
and so on. An aggregate root is a crude way of attempting to answer the
'what is a bite sized chunk' question IMHO.

Another concept not discussed much in DDD is security. The implicit
argument for DDD says  that data is the most important thing, security and
workflows are secondary concerns. Sometimes this is what makes DDD hard to
do. In my estimation I want a balance between all three aspects. Data,
Workflows, and security are all co-influencers. And if you miss one aspect,
which is usually security, it becomes a perennial hack in your code.

For my teams we have another name for security. It is renamed FILTERING
because the data filter aspect of security is far more pervasive and
influential in the systems I design, than is the question 'can I do this'.
In addition, filtering also has a push notification aspect to it, who needs
to know about this, and when? I follow the RACI pattern, responsible,
accountable, consulted, informed. Who needs to have each of those roles.

responsible means the controller of permissions
accountable means the user of permissions
consulted means the in-process colaborators
informed means the post-process announcees

When designing with DDD I have each of the 3 aspects of design, and each of
the RACI actors in mind. I then want to design infrastructure, not
functionality. I used to say design version 3 to build version 1, but that
isnt very clear. What I mean is design infrastructure for data, workflow,
and filtering so that the most difficult problems in the domain are solved,
and remain solved. This is a bit idealistic and the idea of capturing all
that up front is a bit of a nightmare for most people. Ambiguity is the
enemy. This is war. And in the heat of battle it is easy to loose sight of
the objective at times. But that is ok, because as an Architect we have
been through a few battles.

So answering your question means it depends. What are the big chunks?

In my world when we 'publish' the thing is immutable, and we want to be
able to take advantage of that fact by having an ID similar to a DOI that
we can pass around and reference from anywhere. When we do that we get rid
of all the work lint, and just produce the outcome. That might store in the
database in its original form, but it might also just become an
authoritative PDF. Of course you want to keep the artifacts of creation
around for versioning a new instance, a revision, another similar document
of some sort. But when the document prints it should render the database
version frozen, it should make objects immutable and so on in your code.
Which in my mind means they are some other kind of aggregate.


On Tue, Jun 11, 2013 at 2:48 PM, j88bradshaw88 <[email protected]>wrote:

> **
>
>
> 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.
>
>  
>