Re: Sharing binaries/code between client and server in a DDD environment

Firstly, what I was saying is that your value objects look exactly like
DTOs. You haven't made them immutable.


As to where the enum goes. If it's so simple, and unlikely to change, then
copy it or share it. I don't think it really matters.


There are considerations to take into account when sharing a model or part
of a model, whether between client and server or otherwise. Firstly, the
models may be solving very different problems, which means the shared
concepts will tend to weaken and serve neither context well. Secondly,
shared kernels are a notorious place for bugs if they are not kept small,
well-bounded and tightly controlled.


Thirdly, why share anyway? If they truly are different models doing
different things (eg. presentation model and domain model) then just punt
and create new objects. After all, if your presentation model was in a
different language (eg. Javascript) then you would have no qualms about not
sharing. You mention extra complexity if they are not shared, but I'm not
sure I see what extra complexity there would be.


Paul.


On Thu, May 22, 2014 at 1:43 PM, Alastair van Leeuwen
[email protected] [domaindrivendesign] <
[email protected]> wrote:


>
>
> Hi,
>
> Thanks for the reply.
>
> Deliberately omitted DTO’s in order to make the example less complex.
>
> A DTO can also be used off-course:
>
> interface ICustomerMaintenance
> {
>             void CreateCustomer(NewCustomerDto dto);
> }
>
> Where the value objects and primitives reside on the DTO. Now, the DTO’s
> itself can also be shared between the server and client…
>
> The Sex enum is used on the Dto and on Entities:
>
> class Customer : Entity
> {
>     private Sex sex;
> }
>
> The question is, where must Sex be declared and how must it be shared
> using a formal pattern?
> I will have a look at your link.
>
> Regards,
> Alastair
>    On Thursday, May 22, 2014 6:46 PM, "Paul Rayner [email protected][domaindrivendesign]" <
> [email protected]> wrote:
>
>
>
>  The objects you've defined below seem to be functioning more as data
> transfer objects (DTOs) rather than value objects. Especially since you
> have them as part of your service layer, which is outside of the domain
> model, if I am understanding you correctly.
>
> If they are, in-fact, value objects in your domain model, they should be
> immutable and I would recommend you implement everything that flows out of
> that choice. In that case, I have no issues sharing them, so long as you
> adhere to the guidelines for shared kernel:
> https://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf.
>
> Cheers,
> Paul.
>
> On Thu, May 22, 2014 at 8:18 AM, Alastair van Leeuwen
> [email protected] [domaindrivendesign] <
> [email protected]> wrote:
>
>
>  Hi,
>
>  How appropriate is it when sharing binaries or code between a client and
> a server in a DDD environment.
> I by no means advocate sharing the entire Model but just certain common
> aspects.
>
> For example, when using C# with WCF, it is accepted if the service
> interfaces are shared between the client and the server.
> What if this is taken one step further?
>
> For example:
> interface ICustomerMaintenance
> {
>  void CreateCustomer(string Name, string Surname, Sex sex, PhoneNumber
> mobileNumber, PhoneNumber landNumber, ...);
> }
>
> Sex is defined as:
>     enum Sex
>     {
>         Male, Female
>     }
>
> PhoneNumber is a value object defining a phone number.

>
> Although Sex and PhoneNumber are both Value Objects, can they not be
> defined in some common area and shared?
> It seems like extra complexity if these value objects must be re-created
> on the client side.
>
> When sharing these domain concepts in both the client and server, is there
> a special name for it?
> Is it a Shared Kernel or is this term used only when integrating between
> Bounded Context?
>
> There are already common value objects available in C#, such as DateTime.
> If a DateTime did not exist in C#, surely it does not have to be
> re-created on the client and server?
>
> Kind regards,
> Alastair
>
>
>
>
>
>
>
>
>    
>