Re: DRY and cross domain logic

If you implement an interface let say ICalculateAge and that interface
consumed by Client and Patient you can exchange which ever concrete
implementation thats appropriate for each class. I think that solve your
problem architectural wise.


On Tue, May 26, 2015 at 12:53 PM, Tom Eugelink [email protected]
[domaindrivendesign] <[email protected]> wrote:


>
>
> This solves the specific age problem, I was trying to determine an
> architectural pattern.
>
>
> On 25-5-2015 09:10, Rénald VENANT-VALERY [email protected]
> [domaindrivendesign] wrote:
>
>
> Personally, i would use a computed column in the table that stores the
> dates of birth of your third parties. In all domain models that imply the
> client referential, the age is available data and it is always consistent.
>
> 2015-05-22 14:31 GMT+02:00 Tom Eugelink [email protected]
> [domaindrivendesign] <[email protected]>:
>
>>
>>
>> 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
>>
>>
>
>  
>