Does CQS Break Down the Ubiqutous Language?

I was listening to Greg Young on Herding Code and much of what he was saying made perfect sense and stroked my
developer instinct in exactly the right way.  Of course applications shouldn't be just CRUD and of course
it is the behaviors that matter!

One question that I have comes up when Greg talked about avoiding getters and setters in your domain
entities.  I have heard this refrain before and now I feel like I am starting to grasp the reasoning behind
it.  One related thing that he mentioned - and Greg, I know you read this so correct me if I'm wrong - is that it
usually makes more sense to project your display data directly to DTOs rather than having a domain
middle-layer get involved.  

Again, this makes sense but I wonder if it doesn't start to break down the ubiquitous language somewhat?  For
example, when your domain experts discuss a Customer they don't only talk about adding a valid address
which validates against their listed zip code, they talk about being able to check the customer's address
as well!  If you don't have an address getter on the customer, then it seems like when your domain expert says
something like "at this point the customer address should be xyz" you will no longer have a 1-to-1
correspondence between the language and your domain.

Can someone clarify how this is supposed to work? 

------------------------------------

Re: QI4(N?)

Michael Hart wrote:
> Not sure if Roger or Rickard were going to post this, but I just ran
> across it and thought others may be interested too:
> 
> http://rogeralsing.com/2009/06/25/composite-oriented-programming-qi4j-running-on-net/ 
> <http://rogeralsing.com/2009/06/25/composite-oriented-programming-qi4j-running-on-net/>
> 
> Looking forward to seeing how this progresses Roger!

I was on vacation, so I'm glad you posted it! Yes, I agree, it will be 
interesting to see how it progresses!

regards, Rickard

------------------------------------

Re: Does CQS Break Down the Ubiqutous Language?

For 'at this point the customer address should be xyz' 
you don't have to get the address out of the entity.
You could provide the address to the entity that will check internally that the addresses match. 
It can even implement some logic to be a bit lose in the way it matches adresses.

--- In domaindrivendesign <at> yahoogroups.com, "george_mauer" <gmauer@...> wrote:
>
> I was listening to Greg Young on Herding Code and much of what he was saying made perfect sense and stroked my
developer instinct in exactly the right way.  Of course applications shouldn't be just CRUD and of course
it is the behaviors that matter!
> 
> One question that I have comes up when Greg talked about avoiding getters and setters in your domain
entities.  I have heard this refrain before and now I feel like I am starting to grasp the reasoning behind
it.  One related thing that he mentioned - and Greg, I know you read this so correct me if I'm wrong - is that it
usually makes more sense to project your display data directly to DTOs rather than having a domain
middle-layer get involved.  
> 
> Again, this makes sense but I wonder if it doesn't start to break down the ubiquitous language somewhat? 
For example, when your domain experts discuss a Customer they don't only talk about adding a valid address
which validates against their listed zip code, they talk about being able to check the customer's address
as well!  If you don't have an address getter on the customer, then it seems like when your domain expert says
something like "at this point the customer address should be xyz" you will no longer have a 1-to-1
correspondence between the language and your domain.
> 
> Can someone clarify how this is supposed to work?
>

------------------------------------

Re: Does CQS Break Down the Ubiqutous Language?

> ubiquitous language somewhat? For example, when your domain experts discuss
> a Customer they don't only talk about adding a valid address which validates
> against their listed zip code, they talk about being able to check the
> customer's address as well! If you don't have an address getter on the
> customer, then it seems like when your domain expert says something like "at
> this point the customer address should be xyz" you will no longer have a
> 1-to-1 correspondence between the language and your domain.

Why does the state need to be public in order to "check" it in terms
of validation? Can't that happen within the the Customer object?

Also in terms of testing you no longer tend to do tests like these,
instead I would write a test that insured that a "CustomerMovedEvent"
was raised with the proper information. I would also have a test that
showed my object properly handled a CustomerMovedEvent .... This would
not however be based on viewing public state but would instead would
be showing any behavior associated with it.

Cheers,

Greg

On Wed, Jul 1, 2009 at 9:28 PM, george_mauer<gmauer <at> gmail.com> wrote:
>
>
> I was listening to Greg Young on Herding Code and much of what he was saying
> made perfect sense and stroked my developer instinct in exactly the right
> way. Of course applications shouldn't be just CRUD and of course it is the
> behaviors that matter!
>

Re: Does CQS Break Down the Ubiqutous Language?

Interesting.  So are you saying that rather than directly representing the object in the domain the entity
represents the behaviors of the object in a valid state?

That works for me but again it seems like the disconnect would potentially harm the ubiquitous language
that you and your domain expert have worked so hard to establish

--- In domaindrivendesign <at> yahoogroups.com, "jeremie.chassaing" <Jeremie.Chassaing@...> wrote:
>
> For 'at this point the customer address should be xyz' 
> you don't have to get the address out of the entity.
> You could provide the address to the entity that will check internally that the addresses match. 
> It can even implement some logic to be a bit lose in the way it matches adresses.
> 
> 
> --- In domaindrivendesign <at> yahoogroups.com, "george_mauer" <gmauer@> wrote:
> >
> > I was listening to Greg Young on Herding Code and much of what he was saying made perfect sense and stroked
my developer instinct in exactly the right way.  Of course applications shouldn't be just CRUD and of
course it is the behaviors that matter!
> > 
> > One question that I have comes up when Greg talked about avoiding getters and setters in your domain
entities.  I have heard this refrain before and now I feel like I am starting to grasp the reasoning behind
it.  One related thing that he mentioned - and Greg, I know you read this so correct me if I'm wrong - is that it
usually makes more sense to project your display data directly to DTOs rather than having a domain
middle-layer get involved.  
> > 
> > Again, this makes sense but I wonder if it doesn't start to break down the ubiquitous language somewhat? 
For example, when your domain experts discuss a Customer they don't only talk about adding a valid address
which validates against their listed zip code, they talk about being able to check the customer's address
as well!  If you don't have an address getter on the customer, then it seems like when your domain expert says

Application layer without domain logic?

Hi all,

I am currently planning a new billing system for one of our customers.  A few operational systems are going to
user the billing system as a service. When booking a transaction, the operational system must pass the
customer account (an identifier) to be billed, a product (an identifier) and a few more infos. The product
price is based on the customer account and the product so it can be fetched internally.

Now so far I planned to have the following entities:
- Customer Account
- Product
- Price List
- Accounting Record

When booking a transaction a customer account will be debitted. But there can be several cases, that when an
operational system is booking a transaction there is no customer account because the wrong identifier
might have been provided. In this case the transaction needs to be marked as invalid, needs to be stored and
later on repaired by one of the employees by providing the correct information (like an existing customer).

The decisions whether to create and store an invalid transaction record or to store a valid accounting
record are, from my point of view domain logic.

So I was thinking about creating a service that will take care of the above issues like:

BookTransaction(customerId, productId, ...)
{
   customer = repository.find(customerId);
   product = repository.find(productId);
   if(customer == null || product == null)
     // store as invalid transaction
   else

Re: Re: Does CQS Break Down the Ubiqutous Language?

This is not DDD  this is OOP the whole concept of encapsulation. Tell
don't ask is a principle associated with this.

Cheers,

Gre

On Thu, Jul 2, 2009 at 10:48 AM, george_mauer<gmauer <at> gmail.com> wrote:
>
>
> Interesting. So are you saying that rather than directly representing the
> object in the domain the entity represents the behaviors of the object in a
> valid state?
>
> That works for me but again it seems like the disconnect would potentially
> harm the ubiquitous language that you and your domain expert have worked so
> hard to establish
>
> --- In domaindrivendesign <at> yahoogroups.com, "jeremie.chassaing"
> <Jeremie.Chassaing@...> wrote:
>>
>> For 'at this point the customer address should be xyz'
>> you don't have to get the address out of the entity.
>> You could provide the address to the entity that will check internally
>> that the addresses match.
>> It can even implement some logic to be a bit lose in the way it matches
>> adresses.
>>
>>
>> --- In domaindrivendesign <at> yahoogroups.com, "george_mauer" <gmauer@> wrote:

Re: Re: Does CQS Break Down the Ubiqutous Language?

Re: Re: Does CQS Break Down the Ubiqutous Language?

Giovanni,

The state *is* there ... it is just not exposed nor should it be. It
does not affect the ubiquitous language because the state is still
there  when you rationalize about the object it still has state but
when anything else interacts with it it interacts through behaviors.
In the validation example given the state verification is still
happening, it is happening *inside* the object where the state is
visible as opposed to outside. The fact that the object has attributes
and state has not changed ... only the exterior visibility of that
state.

The only time it causes a problem with the ubiquitous language is when
the ubiquitous language was pretty nasty in the first place (a perfect
example would be the ubiquitous language surrounding an anemic domain
eg nouns and "verb noun"s). In these cases focusing on not exposing
state but moving to behavioral objects actually *improves* the
ubiquitous language.

Cheers,

Greg

On Thu, Jul 2, 2009 at 12:38 PM, Giovanni Bassi<giggio <at> giggio.net> wrote:
>
>
> Greg, I believe you are missing the point. George is not asking about OOP or
> best principles, but only if this practice hurts the Ubiquitous language as
> he sees it. And he does have a point.
>
> Cheers!
>
> On Thu, Jul 2, 2009 at 12:18 PM, Greg Young <gregoryyoung1 <at> gmail.com> wrote:
>>
>>
>> This is not DDD this is OOP the whole concept of encapsulation. Tell
>> don't ask is a principle associated with this.
>>
>> Cheers,
>>
>> Gre
>>
>> On Thu, Jul 2, 2009 at 10:48 AM, george_mauer<gmauer <at> gmail.com> wrote:
>> >
>> >
>> > Interesting. So are you saying that rather than directly representing
>> > the
>> > object in the domain the entity represents the behaviors of the object
>> > in a
>> > valid state?
>> >
>> > That works for me but again it seems like the disconnect would
>> > potentially
>> > harm the ubiquitous language that you and your domain expert have worked
>> > so
>> > hard to establish
>> >
>> > --- In domaindrivendesign <at> yahoogroups.com, "jeremie.chassaing"
>> > <Jeremie.Chassaing@...> wrote:
>> >>
>> >> For 'at this point the customer address should be xyz'
>> >> you don't have to get the address out of the entity.
>> >> You could provide the address to the entity that will check internally
>> >> that the addresses match.
>> >> It can even implement some logic to be a bit lose in the way it matches
>> >> adresses.
>> >>
>> >>
>> >> --- In domaindrivendesign <at> yahoogroups.com, "george_mauer" <gmauer@>
>> >> wrote:
>> >> >
>> >> > I was listening to Greg Young on Herding Code and much of what he was
>> >> > saying made perfect sense and stroked my developer instinct in
>> >> > exactly the
>> >> > right way. Of course applications shouldn't be just CRUD and of
>> >> > course it is
>> >> > the behaviors that matter!
>> >> >
>> >> > One question that I have comes up when Greg talked about avoiding
>> >> > getters and setters in your domain entities. I have heard this
>> >> > refrain
>> >> > before and now I feel like I am starting to grasp the reasoning
>> >> > behind it.
>> >> > One related thing that he mentioned - and Greg, I know you read this
>> >> > so
>> >> > correct me if I'm wrong - is that it usually makes more sense to
>> >> > project
>> >> > your display data directly to DTOs rather than having a domain
>> >> > middle-layer
>> >> > get involved.
>> >> >
>> >> > Again, this makes sense but I wonder if it doesn't start to break
>> >> > down
>> >> > the ubiquitous language somewhat? For example, when your domain
>> >> > experts
>> >> > discuss a Customer they don't only talk about adding a valid address
>> >> > which
>> >> > validates against their listed zip code, they talk about being able
>> >> > to check
>> >> > the customer's address as well! If you don't have an address getter
>> >> > on the
>> >> > customer, then it seems like when your domain expert says something
>> >> > like "at
>> >> > this point the customer address should be xyz" you will no longer
>> >> > have a
>> >> > 1-to-1 correspondence between the language and your domain.
>> >> >
>> >> > Can someone clarify how this is supposed to work?
>> >> >
>> >>
>> >
>> >
>>
>> --
>> Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
>> de votre attention
>
> 

--

-- 
Les erreurs de grammaire et de syntaxe ont été incluses pour m'assurer
de votre attention

------------------------------------

Presentation Models