Aggregate that spans multiple contexts

Question

I am trying to move a legacy system which doesn't really have any architectural discipline, to abide by DDD principles. The system has payroll and invoicing processes involved so I have created a Payroll and Billing BC to reflect those boundaries.

The issue I have, which may be a modelling problem (Still new to DDD so bear with me!) is that in the current system there is a Client page.

This has some general details, some information that relates to payroll and some that relates to invoicing.

Would this be its own BC which holds all the information and communicates the payroll/invoicing related information via events, or would it be a case of have a shared kernel and associated services/repositories for managing clients?

Take this simplified model:

{
    Id : 0,
    Name : "",
    Ref : "",
    BillingAddress : {
        //Address details for sending invoices to, should be in Invoicing BC
    },
    PayrollDetails : {
        //Details relating to payroll, should be in Payroll BC

    }
    //Some other properties that aren't relevant in invoicing or payroll

}

there was a link inside there to :https://stackoverflow.com/questions/17916722/bounded-contexts-in-ddd-with-cqrs-sharing-aggregates-entities-possible?rq=1 would having one BC 'own' the client, and the other storing a reference to it be an acceptable approach? e.g. the payroll BC will own the client, and events will sync the billing details with the invoicing BC, but not store billing details in the payroll BC? — Steven Brookes, Jan 25 '18 at 11:55
This seems to put too much responsibility on that *BC*. By `BC` you understand `module` (or whatever mechanism for modularization you use)? — Constantin Galbenu, Jan 25 '18 at 12:01
Each BC should own only the data that it mutates. You can have other BCs that aggregate the data, but only in a read-only manner, i.e. to present them to the user or to query them faster or more appropriate for a use-case. — Constantin Galbenu, Jan 25 '18 at 12:04
The system at this allows the use to enter details that relate to both BCs at point if creation, so was wondering how I'd handle that, which is where I was thinking of a client BC which would issue events to payroll and invoicing to sync the relevant information — Steven Brookes, Jan 25 '18 at 12:14
If you think your aggregate needs to span over multiple bounded contexts means you did not correctly identity your aggregates. Two aggregates in different context may be called same but have different meaning. For example vacation from point of employee has different meaning the "request vacation" context than vacation to the personal personnel manager who approves or rejects. the request vacation context is to find a timeframe and "vacation replacement" where as personnel manager is to approve it and i.e. add it to the vacation calendar. — Tseng, Jan 25 '18 at 12:19
@StevenBrookes It depends on what the consistency do you need. The simplest way is to just send two (different) commands to each BC directly from the UI. — Constantin Galbenu, Jan 25 '18 at 12:23
@Tseng an `Aggregate` *may* have different **read-only/immutable and partial representations** in multiple bounded contexts. Every complex domain works that way. — Constantin Galbenu, Jan 25 '18 at 12:28
@ConstantinGalbenu: Sure, but that's views/projections. But its not an aggregate in these other BCs. The title says states _Aggregate that spans multiple contexts_ which is just a wrong assumption. An aggregate is limited to its BC, it **can not** span over multiple BC. No exceptions. When you need to obtain data from other BC you use DTOs over an Anti-Corruption layer which prevents changes from one BC affecting all other BCs and transforms the data into a structure suitable for the calling BC. — Tseng, Jan 25 '18 at 13:04
But actually what the OP has is an pure UI concern. _the current system there is a Client page_ >> means a website or UI page (such as in mobile or desktop app). Its unrelated to the domain itself, its about presentation. And there you're outside of the BCs and can use DTOs or ViewModels (when applying MVVM pattern) to bring the data in **any shape** necessary to present it to the UI/user — Tseng, Jan 25 '18 at 13:06
@Tseng Exactly, I ignored the title, as the OP is new to DDD: `Still new to DDD so bear with me!`). Now, I'm trying to understand what are the OP's business requirements. — Constantin Galbenu, Jan 25 '18 at 13:11
At the moment I was more worried about writing the information that reading it :P I added a comment to VoiceOfUnreason's answer, asking if the controller would orchestrate the sending of commands to the different BC Application Services, but wondered about information not related to either context and where that would be stored (would it just be duplicated in each BC?) — Steven Brookes, Jan 25 '18 at 14:27

VoiceOfUnreason · Accepted Answer · 2018-01-25T16:38:45.297

Would this be its own BC which holds all the information and communicates the payroll/invoicing related information via events, or would it be a case of have a shared kernel and associated services/repositories for managing clients?

You might be looking for a compositional UI design; Udi Dahan wrote several times about this pattern.

So would I have the controller orchestrate sending the required commands to the different BCs?

It might be the controller, it might be somewhere else -- depends on how aggressively you like to separate concerns and what degree of re-use you can expect.

How about the information that isn't really required in either BCs?

Then pull that information out of a cache somewhere else?

That information needs to be persisted somewhere, which is why I asked if that would mean that I'd have something like a Client Management BC for that?

Customer Relationship Management (CRM) is often its own context, with its own concerns, yes.

So would I have the controller orchestrate sending the required commands to the different BCs? How about the information that isn't really required in either BCs? — Steven Brookes, Jan 25 '18 at 14:23
What was meant by information not relating to either BC was that, for example, a client may have contact details, which isn't something that is required for payroll or invoicing. That information needs to be persisted somewhere, which is why I asked if that would mean that I'd have something like a Client Management BC for that? — Steven Brookes, Jan 25 '18 at 15:19

Aggregate that spans multiple contexts

1 Answers1