Re: DRY and cross domain logic

> Secondly, you could implement the logic in both bounded contexts. I'm
less concerned about DRY across bounded contexts, since we are talking
about different models.

That was my thought. Is everyone working on those 2 BCs or do different
teams each have their own BC?

I'd say over time it may actually be okay to have some code duplicated in
that situation, as it starts getting hard to have both teams in total sync.

On Fri, May 22, 2015 at 3:12 PM, Paul Rayner [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> I see (at least) three options, with various tradeoffs: Firstly, the
> Client bounded context could provide an Open Host Service that takes in the
> relevant info and reports out the result, which the Patient bounded context
> could then call. This seems the likely candidate if several
> entities/aggregates are required from Client.
>
> Secondly, you could implement the logic in both bounded contexts. I'm less
> concerned about DRY across bounded contexts, since we are talking about
> different models.
>
> Thirdly, share the logic in some way (abstract base class etc), which
> gives you a Shared Kernel. Shared Kernels are tricky to get right, and
> given what you've said about the algorithm and the potential need for other
> entities, I'd be wary of this one.
>
> Paul.
>
> On Fri, May 22, 2015 at 8:02 AM, Tom Eugelink [email protected]
> [domaindrivendesign] <[email protected]> wrote:
>
>>
>>
>> But what if the input of the algorithm requires other entities in the
>> Client's BC? The output may be simple, but maybe the age calculation also
>> depends on the country where the client is born, because they use a
>> different calendar (e.g. Chinese). The country is not present in Patient's
>> BC.
>>
>> Tom
>>
>>
>> On 22-5-2015 15:09, Jose Fernandez [email protected]
>> [domaindrivendesign] wrote:
>>
>>
>> Just create  base class with common members and methods. Inherit your AR
>> from it.
>>
>>  public class Person
>> {
>> public DateTime BirthDate;
>> public int CalculateAge()
>> {
>> return age here;
>> }
>> }
>>
>>  Public class Client: Person, IAggregateRoot
>>
>>  Same for Patient.
>>
>> Sent from my iPhone
>>
>> On May 22, 2015, at 8:31 AM, 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
>>
>>
>>
>  
>