Re: DRY and cross domain logic

You mentioned this is something that can't be done with events, is that a
technical limitation of the toolset you are using? Or is it that you can't
see a way of using events that is suitable?

What is the data in question being used for in each of the BC's? Maybe your
representation in one of the BC's is not correct for it's function.

Using your date of birth and age calculation example, maybe Age is actually
the important information for the second BC - it doesn't need the date of
birth to function (where is date of birth maintained and how is it sync'd
if changed in one but not the other - something is potentially leaking). If
it is the case that age is all that is needed in the second BC, the first
BC (that owns the date of birth) could raise an aged changed event
containing the new age on the birthday of each client.



/*
Email: [email protected]
Twitter: @simonmfox
*/

On 23 May 2015 at 04:28, Jose Fernandez [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> Like I said, a value object is the best route.
>
> Sent from my iPhone
>
> On May 22, 2015, at 9:15 AM, Freek Paans [email protected]
> [domaindrivendesign] <[email protected]> wrote:
>
>
>
> I would do either
>
> 1) Create an age class and treat it like framework code (ie share it
> between BCs)
> 2) Implement it twice, since it's not exactly complicated and pretty
> stable.
>
> -Freek
>
> On Fri, May 22, 2015 at 2:31 PM, Tom Eugelink [email protected]
> [domaindrivendesign] <[email protected]> wrote:
>
>>
>>
>> We have a discussion in my current project group about the following:
>> - There are two bounded context.
>> - In each bounded context there is an person-alike entity, in one BC it
>> is Client in the other it is Patient, mostly with their own business logic
>> and methods specific to their roles.
>> - However, at some point Patient requires some determining logic that is
>> implemented in Client. For simplicity let's assume both have a
>> date-of-birth and the to-be-called logic is calculateAge().
>>
>> This is not something that can be done with events, and because of DRY
>> you do not want to implement calculateAge() twice. What is the best option
>> to calculate the age of a patient? Client and Patient share a unique id, so
>> Patient knows which Client to get. (N.B. I seek a conceptual solution, not
>> one specific to the calculate age problem.)
>>
>> Tom
>>
>>
>   
>