Hi Greg, thanks for a very detailed response.
Re point 1:
I'm not sure what you mean by 'external functionality' ... I didn't say I
was exposing the service layer to anything other than my client (the article
suggested an example of WinForms/WPF). Were you assuming that I was
exposing my services to other applications?
I can't quite grasp how I have 'lost any concept of encapsulation' - just
because domain objects were sent across the wire, doesn't mean a client can
modify my database, does it?
Re point 2:
I'm not sure what you mean by having lost ''the concept of having a
meaningful architectural seam". Hopefully my service layer would have
meaningful methods on it, but I'm not sure how this would be obscured from
the client by passing a domain object rather than a DTO.
Re point 3:
Agreed - if the wire protocol requires it I will create a DTO (as stated
originally).
However, I do find a lot of the time the service layer exposes calls to 'get
a list of objects' to populate lists/drop-downs etc. In these cases I find
the domain objects the ideal thing to pass across the wire.
Re point 4:
Absolutely - I would only hope to send back what is required (the original
article covers not taking too much of the domain). However, just to
clarify, I (personally) wouldn't write a DTO just to save myself passing
'one or two' of the properties on my domain objects - I would wait until I
'needed' this (need unfortunately might be subjective).
Re point 5:
Agreed - and I think this is related to exposing your services to other
applications (point 1). If you have to handle multiple clients (some of
which you may not be in control of), and also handle versioning, then you
should protect yourself behind suitable DTOs.
I wasn't trying to address this (much more complex problem) in the original
post - I was addressing the problem of a remote presentation layer, but
where you are still in control of the whole application.
Re point 6:
Yes - again I was imagining the presentation layer being deployed inline
with the service layer (e.g., ClickOnce). If this wasn't feasible, then
again you're right you might have to handle versioning.
Thanks again for such a detailed response. It has raised points that would
need to be addressed in a more complicated application/environment than the
article originally intended.
If I was in control of both ends of the communication, and didn't have to
worry about versioning, then I'd still start by passing domain objects, and
introduce DTOs where I thought they were necessary.
Overall though, I suspect it's possible we share more in common with
designing applications than we disagree on.
Regards,
Richard
--------------------------------------------------
From: "Greg Young" <[email protected]>
Sent: Thursday, February 05, 2009 5:40 PM
To: <[email protected]>
Subject: [nhusers] Re: Should I use NHibernate+WCF?
>
> The issue at hand was why you don't put domain objects on the wire
> directly.
>
> Here's a few reasons.
>
> 1) You can't vary your internal functionality separately from your
> external functionality. You have lost any concept of encapsulation.
> 2) You lose the concept of having a meaningful architectural seam
> 3) Your wire protocol generally should not match up with your domain
> model (you want to focus on use case/ui analysis to minimize round
> trips which will lead to data from multiple aggregates etc being sent
> at once). I think you will find it hard to find people who believe in
> chatty interfaces, the way to get rid of chatty interfaces is to focus
> on making screens 1-1 with calls on your api. The domain is focused on
> how best to execute your transactions
> 4) Sending too *much* data. Often I only need some subset of a graph,
> opposite problem as #3
> 5) You lose any hope of being able to versionize your contract (let's
> talk about how deployment works again in your distributed
> environment?)
> 6) You are allowing clients to take dependencies on the shape of your
> domain ... again lets talk about deployment?
>
>
> re: anti-pattern discussion: this has been beaten to death on the DDD
> lists.
>
> Consider for a moment that this boundary is an anti-corruption layer
> for your domain from those who use it and vice-versa. There are very
> limited places where you may want to break this rule but the
> difficulty is in finding those limited places that also fit into where
> you would want to use a domain model.
>
> Greg
>
>
> On Thu, Feb 5, 2009 at 12:18 PM, Richard (Google)
> <[email protected]> wrote:
>>
>> Is that a requirement to implement Domain Model + Service Layer + Remote
>> Facade?
>>
>> --------------------------------------------------
>> From: "Greg Young" <[email protected]>
>> Sent: Thursday, February 05, 2009 5:14 PM
>> To: <[email protected]>
>> Subject: [nhusers] Re: Should I use NHibernate+WCF?
>>
>>>
>>> Can you make changes to your "data on the inside" without affecting
>>> your "contract on the outside"?
>>>
>>> Cheers,
>>>
>>> Greg
>>>
>>> On Thu, Feb 5, 2009 at 12:13 PM, Richard (Google)
>>> <[email protected]> wrote:
>>>>
>>>> Can you explain the bit that's an anti-pattern? (citing a source if
>>>> possible?)
>>>>
>>>> --------------------------------------------------
>>>> From: "Greg Young" <[email protected]>
>>>> Sent: Thursday, February 05, 2009 5:11 PM
>>>> To: <[email protected]>
>>>> Subject: [nhusers] Re: Should I use NHibernate+WCF?
>>>>
>>>>>
>>>>> Why do you not need them?
>>>>>
>>>>> Do you understand all of the arguments against your current
>>>>> methodology? What you are doing is an anti-pattern in most contexts.
>>>>>
>>>>> Greg
>>>>>
>>>>> On Thu, Feb 5, 2009 at 12:10 PM, Richard (Google)
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>> I DO start with the domain objects (or really their tests). In an
>>>>>> ideal
>>>>>> scenario, the database comes next from SchemaExport()).
>>>>>>
>>>>>> Anything else I might need would be generated from the domain
>>>>>> objects,
>>>>>> but
>>>>>> if I don't need DTOs I don't see any need to complicate things
>>>>>> further.
>>>>>>
>>>>>> Cheers,
>>>>>> Richard
>>>>>>
>>>>>> --------------------------------------------------
>>>>>> From: "Greg Young" <[email protected]>
>>>>>> Sent: Thursday, February 05, 2009 5:03 PM
>>>>>> To: <[email protected]>
>>>>>> Subject: [nhusers] Re: Should I use NHibernate+WCF?
>>>>>>
>>>>>>>
>>>>>>> see qualification "If you are heads down coding CRUD stuff"
>>>>>>>
>>>>>>> Why not define it in metadata and generate everything?
>>>>>>> Why not generate from the database?
>>>>>>> Why not go another way and create your domain class then generate
>>>>>>> everything else?
>>>>>>>
>>>>>>> simple CRUD ... the models are all the same it doesn't matter which
>>>>>>> one you start with.
>>>>>>>
>>>>>>> Greg
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> It is the mark of an educated mind to be able to entertain a thought
>>>>> without accepting it.
>>>>>
>>>>> >
>>>>>
>>>>
>>>> >
>>>>
>>>
>>>
>>>
>>> --
>>> It is the mark of an educated mind to be able to entertain a thought
>>> without accepting it.
>>>
>>> >
>>>
>>
>> >
>>
>
>
>
> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
