Re: DRY and cross domain logic

That will not work for enterprise customers. Parties with references cannot
be avoided.
Rémy.

On 22 May 2015 at 15:09, Jose Fernandez [email protected]
[domaindrivendesign] <[email protected]> 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
>
>   
>