>>
Then he is a domain expert, because the business is your companies business,
and your product, therefore your DE would be the expert on your product
<<

Sure, I agree, but at the same time he is also a proxy for the different
requirements of each customer.


Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com - Think domain, not database

Hi all - sorry for bringing this thread alive again - I know a couple of you
feel I've been
quite noisy, so I'll pipe down after this.

However, I just stumbled across a nice talk by Gojko Adzic, which I thought
might be
useful for anyone following the conversation (for those who haven't seen it
yet):

http://video.google.com/videoplay?docid=-5503593116153624917

(around 37:00)

He talks about a separate Aggregate Root object (basically for the same reasons,
but
probably explained more clearly than I did) and he mentions that it was brought
up on the
mailing list a while back, so again, sorry for the rehash (but I haven't found
it in my brief
searching attempts yet).

He also mentions that Evans had brought it up in a course a couple of months ago
- was
anyone on the list there, and was there anything more to add?

--- In domaindrivendesign@yahoogroups.com, Michael Hart <michael.hart.au@...>
wrote:
>
> While I realise that one of the properties of an Aggregate is to
> choose an Entity that serves as the root of that boundary, is everyone
> actually using that Entity class to serve as the contract of the
> boundary itself? Or do you use a separate object (eg,
> CustomerAggregateRoot) that serves this purpose, which in turn holds a
> reference to the root Entity (Customer)?
>
> The main reason that I ask is that it strikes me that the root Entity
> would end up with a lot of responsibility if it's controlling all
> external access, as well as acting as a transactional boundary and
> enforcing all the invariants of the contained objects - as well as all
> of the regular domain behaviour specific to the Entity itself.
> Basically it feels a bit like an unnecessary violation of SRP - not
> that principles always apply, but still...
>
> If you had a separate Aggregate Root object, it strikes me that it
> might be beneficial to view it as a specific type of Domain Service -
> ie, one that only deals within one Aggregate boundary. As with other
> Services, it would have the responsibility of dealing with explicit
> Units of Work, invoking Repository methods and processing external
> messages (if that's the way you swing). And then there'd be Aggregate-
> specific responsibilities like exposing externally required Factory
> methods.
>
> Does anyone do this? Or do people find the responsibilities of being
> an Aggregate Root still fit nicely on the root Entity itself?
>

Thanks for posting this.  This is the meeting I tried to attend but the
British motorway system conspired against me :-)


Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com - Think domain, not database

Thanks Randy I have been wanting to watch these!

Greg

On Mon, Feb 2, 2009 at 3:13 PM, Randy Stafford
<randy.stafford@...> wrote:
> Hi All,
>
>
>
> Videos of the Oredev conference sessions (including the DDD track) were
> finally posted about a week ago.  Here's the URL in case you're interested:
>
> http://www.oredev.org/topmenu/video.4.45b270a411a9ed8e1278000948.html
>
>
>
> Cheers,
>
> Randy
>
>



--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

Carlos,

In all cases where I needed to show a calculated value, I stored it as well
(but usually only in the bounded context dealing with queries).

--
Udi Dahan - The Software Simplist


> -----Original Message-----
> From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Carlos Peix
> Sent: 02 February 2009 22:46
> To: domaindrivendesign@yahoogroups.com
> Subject: RE: [domaindrivendesign] Re: CQS
>
> Hi,
>
> I was following this thread and, additionally, I saw the interview to
> Greg posted a few days ago and I still have some caveats regarding the
> DTO generation directly from the data store, without mapping objects
> from the domain model (that is, the Q part of the pattern).
>
> One of them is, what if I need on those DTOs a property not present in
> the data store, for example a calculated property?
>
> Thanks
>
> Carlos Peix
>
> ________________________________
>
> De: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] En nombre de Udi Dahan
> Enviado el: Lunes, 02 de Febrero de 2009 10:42 a.m.
> Para: domaindrivendesign@yahoogroups.com
> Asunto: RE: [domaindrivendesign] Re: CQS
>
>
>
> Eben,
>
> Auditing needs to understood at two different levels - between
> services,
> where it often takes the form of business activity monitoring, and
> within a service, where it may be done using various techniques (like
> triggers).
>
> In order to come up with a feasible auditing solution, one needs
> specific requirements, and only then can the utility of various
> techniques be compared.
>
> --
>
> Udi Dahan - The Software Simplist
>
> From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eben Roux
> Sent: 02 February 2009 09:38
> To: domaindrivendesign@yahoogroups.com
> Subject: [domaindrivendesign] Re: CQS
>
> Hey Udi,
>
> "If the command in your example is 'submit order', then that would be
> copied for the audit trail."
>
> Yes, that makes sense and I get it. What I am trying to "get more" is
> that whole little 'submit order' bit. Does the command-audit save all
> the data for the command or does it simply save the event with some
> very pertinent correlation data?
>
> Let's say that once the order is accepted the stock service has to
> receive a 'reduce stock' command so:
>
> REDUCE STOCK: Product-DDD, Quantity-1
>
> The Stock record contains say, like, 50 fields (hypothetically) so our
> audit should tell us what happened ('reduce stock') but also just the
> data that changed --- else to get what exactly happed we have to
> compare data. In this example the comparison may only involve v1 and
> v2 of a record, but there may be instance where a whole bunch of data
> is changed...
>
> Anyway, will get to a solution one way or the other.
>
> Regards,
> Eben
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.15/1923 - Release Date:
> 01/02/2009 18:02
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.15/1923 - Release Date:
> 01/02/2009 18:02

we can see it as a opportunity. because the team is already have a
ubiquitous language. :) but maybe not all the essence of the domain
will be captured.

--- In domaindrivendesign@yahoogroups.com, Casey Charlton <casey@...>
wrote:
>
> Its not a great idea, but its better than nobody appointed as a DE :)
>
> 2009/2/2 Colin Jack <colin.jack@...>
>
> >   Hi All,
> >
> > On my current project we won't have access to domain experts, instead
> > we'll have access to proxy domain experts within the team (primarily
> > senior developers who worked on the system that we are writing a
> > replacement for).
> >
> > My experience is that going full on with DDD in this sort of situation
> > is not a good idea, at best you end up producing a great domain model
> > that is quite probably not fit for purpose. You waste a lot of
time and
> > effort and end up with very little to show for it.
> >
> > So I'm wondering, do any of you have techniques to make DDD work with
> > proxy domain experts? Do any of you think its even a good idea?
> >
> > Ta,
> >
> > Colin
> >
> >
> >
>

Udi Dahan skrev:
> In all cases where I needed to show a calculated value, I stored it as well
> (but usually only in the bounded context dealing with queries).

Hi Udi,

Maybe you have a suggestion to the following problem.

Consider a leasing application dealing with contracts, vehicles and
customers. A contract has a leasing period, and refers to exactly one
customer and one vehicle. A customer can refer to many contracts
(assuming the leasing periods do not overlap). Likewise a vehicle can
refer to many contracts (again assuming the leasing periods do not overlap).

All of these domain concepts have a status.

For a contract the possible states are Offer, Active, Expired, and
Canceled. Offer means that the contract has not been signed yet by the
customer. Active means that the contract is signed and that the current
date is within the leasing period. Expired means that the contract is
signed and that the current date is after the last date of the leasing
period. Canceled means that the contract was canceled before it was signed.

For a customer the possible states are Prospect, Existing, and Former.
Prospect means that the customer has never signed a contract, i.e. every
contract that refer to the customer has status Offer or Canceled.
Existing means that the customer has at least one contract which has
status Active. Former means that the customer has no contracts with
status Active and at least one contract with status Expired.

For a vehicle the possible states are Available and Occupied. Available
means that there are no contracts with status Offer or Active that refer
to the vehicle. Occupied means that there is a contract with status
Offer or Active that refer to the contract.

Based on these definitions we now have the following situation:
   - The status of a contract depends on the current date
   - Both statuses of a customer and a vehicle depend on the status of a
contract, and thus indirectly depend on the current date.

As far as I can see it, it is not desirable to store the (calculated)
status values since they all depend on the current date and eventually
will become invalid. The only solution I see is to calculate them every
time I need them, either directly in the database query or by fetching
enough information to calculate them in the presentation model using
some kind of calculation class as suggested by Michael Hart.

Do you have an alternative solution?

Regards,
--
Jonas

Hello Carlos,

> So, in this scenario, I should persist the result of one method
> (order.Total(), for example) in my model so I have it available for
> querying.
>
> Is that what you are proposing?

My opinion:

This is exactly it.  But not necessarily in the same data store as
your domain --- although there is nothing wrong with storing it along
with the domain data if you want to use a single data store for both
writing and querying.

However, there are situations where you cannot calculate domain values
up-front.  In cases such as those it may be possible to issue a
command first to perform domain-cleverness and store to a temporary
result set which is queried after the successfull write.

Regards,
Eben

Hi Jonas,

basically it does not matter how complex or not some calculations are.
You could "freeze" any state into staleness.

Jonas Kongslund schrieb:
> Based on these definitions we now have the following situation:
> - The status of a contract depends on the current date
> - Both statuses of a customer and a vehicle depend on the status of a
> contract, and thus indirectly depend on the current date.
>
> As far as I can see it, it is not desirable to store the (calculated)
> status values since they all depend on the current date and eventually
> will become invalid. The only solution I see is to calculate them every
> time I need them, either directly in the database query or by fetching
> enough information to calculate them in the presentation model using
> some kind of calculation class as suggested by Michael Hart.

Some possible solutions come to mind:
AvailableUntilDate
OccupiedUntilDate
and even the contract/vehicle States itself

It's the question which "calculated" values you freeze into persistance.
And the other what how much time will proceed between showing this data
and performing the next action based on it.

Basically take a point in time and think about what kind of data
information you need to exactly show that particular point with all
available information to somebody.
And after you've done you actually have presented that point to the UI.
And now define the "next" point you are willing to show that same user
of the UI.
The span between those points and the requirement to show new
information is called your work ;-)

Hope that helps [or like Udi says: Hope, that makes sense :-) ]

Nino

Hi again Jonas,

my first response was some kind of stupid so here is a better try:

Greg and me had an example of a stock trading application.
It has far more complexity than your example.

Take two "screens" for showing up stock data:

Timepoint A:
Stock ISIN: ABXH
Last exchange rate: 2.25
Bid 2.33
Ask 2.18
Trading volume 2000

Timepoint B:
Stock ISIN: ABXH
Last exchange rate: 2.25
Value bid 2.35
Value ask 2.16
Trading volume 2500

Assuming you are showing this data, it is based on available information
at timepoint B now. If you refresh it a difference will be shown (or not).
Taking actions now will lead the application to take the most current
values out of somewhere to perform that task and show you the results of
that new Timepoint C or will just tell you it has succeded or not.
Normally, at least my web-based trading system, shows me time in
minutes. That's an eon for stock trading, but I'm used to it and know
that the data I see is not the data I operate on, even as a user of the
application.

All the stuff that happens between A and B, and also between B and C is
either reading (new) data or performing an action/command.

Now it depends on your application what latency i.e. staleness the
presentation has. The domain i.e. the action someone takes performing
something has no latency (not a technical one) but always operates on
the most "fresh" data available.

Taking your example: a clerk of your company is being asked what status
the contract has (it's 23:49:30), some screen shows up loading the data
for presentation, all data that is needed to show information of *that*
timepoint.
It could be frozen at 23:49:29. Now he performs some action on the
contract, say at 00:00:01, the application does not operate on the data
of the former screen but on the most current available. And things have
changed.

So if you show that same information for that contract 12 minutes later
it has changed. Now it's your work to either provide a way to show that
change or to say "it does not matter", because all actions are performed
"live".

Hope that helps a little more.
Nino

Wow, Casey Einstein?
;-)

Casey Charlton wrote:
>
>
> Reminds me - a long time ago I worked for Citibank FX ... one of their
> Reuters screens was updating around 1/3rd of a second behind others,
> this was a major issue for them, had half of IT on the case for a week
> to resolve it... time is relative
>

Nowadays time AND money is also relative for Citibank...

Casey Charlton wrote:
>
>
> LOL ... the point is, of course the 1/3rd of a second was totally and
> utterly meaningless (the data was probably already a few seconds or more
> behind the market, it was 1997), but the *perception* of a delay caused
> otherwise rational FX traders to panic that they may be losing money
> because of it.

Yepp, that's another consequence of designing UIs and the presentation
logic behind: depending on the context and the intelligence of the
people using it. It can be very extreme like in your example.
Have you "solved" the problem?

Hey Carlos,

I am so angry now I am actually shivering --- just kidding *lol*

It might smell... but I think it smells good.

You know, at that point in time your data reflects the state its in.
If there are more 'fluid' calculations then these *obviously* cannot
reflect a current state.

But you have to do what works for you.  I am going to give this CQS a
good ol' bash and see what pops out.

Regards,
Eben

Does someone know, what the status of QCon SF videos is?

-Sebastian

Greg Young schrieb:
>
>
> Thanks Randy I have been wanting to watch these!
>
> Greg
>
> On Mon, Feb 2, 2009 at 3:13 PM, Randy Stafford
> <randy.stafford@... <mailto:randy.stafford%40oracle.com>> wrote:
>  > Hi All,
>  >
>  >
>  >
>  > Videos of the Oredev conference sessions (including the DDD track) were
>  > finally posted about a week ago. Here's the URL in case you're
> interested:
>  >
>  > http://www.oredev.org/topmenu/video.4.45b270a411a9ed8e1278000948.html
> <http://www.oredev.org/topmenu/video.4.45b270a411a9ed8e1278000948.html>
>  >
>  >
>  >
>  > Cheers,
>  >
>  > Randy
>  >
>  >
>
> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>
>

HI all,

A proxy is not necessarily a problem. It largely depends on the context and on
the
domain.
But there are too many question marks open here, so I like Casey's
recommendation here.
I'b probably start something similar: "Aggressively search for domain experts".
Sometimes
this is a feasible way, somatimes it's hgarder, but will give you a warning sign
if your
proxy DE is dragging you off track or not.

I've been in a similar situation and I was really worried, because our DE was
not a real DE
but had been involved in the previous implementation of the application (15
years before)
so:
- he knew the application, and though he knew the domain.
- he wasn't to inclined to admit that things could have been done differently.

Later it turned out that the users were so used to the old application that they
liked the
new one just because there was nothing new to learn. No breakthrough, no real
competitive advantage, but the same old stuff... with a different technology.
Maybe doing
full DDD in such a scenario could be a waste. On the other hand sometimes older
version
of the application are part of the overall domain, and this must be considered
too....

best regards

Alberto



--- In domaindrivendesign@yahoogroups.com, Casey Charlton <casey@...> wrote:
>
> No experts because?
> If you are an ISV, start a simple model, phone 3-4 of your best customers,
> buy them lunch and ask them to rip your ideas to pieces
>
> 2009/2/2 Colin Jack <colin.jack@...>
>
> >   > Te proxy *thinks* they know more than all the customers combined, the
> > > whole point of DDD is that they almost certainly do not.
> >
> > So in this case I think we should consider falling back to simpler
> > methods where the tech team design solutions that suit them, forgetting
> > about a shared model and UL.
> >
> > These simpler methods are a liability I admit, but they are easier for
> > junior developers to understand and in my experience are as successful
> > as DDD *if* you don't have domain experts to discuss the model with.
> >
> > Am I wrong?
> >
> >
> >
>

> What is missing from your description is that after the domain's state is
> persisted, an event is published from that bounded context.

Do you have some form of persisted event subscription mechanism, or is it an
event mechanism where some non-persistent class subscribes to something and
then loads up the relevant entities to notify them?


Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com - Think domain, not database

It may or may not have its own data store.

When it does the adding of the information as denormalized within the
events is a good one.

Cheers,

Greg

On Tue, Feb 3, 2009 at 2:44 PM, Carlos Peix <peix-listas@...> wrote:
> Hi Udi,
>
> I now realize that the query bounded context has his own persistence
> support. I was thinking that the queries were resolved with the main data
> store, whichever directly or moved to a separate db/server with simple
> transformations.
>
> Now I guess I get it.
>
> Thanks
>
> Carlos Peix
> ________________________________
> De: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] En nombre de Udi Dahan
> Enviado el: Martes, 03 de Febrero de 2009 11:39 a.m.
> Para: domaindrivendesign@yahoogroups.com
> Asunto: RE: [domaindrivendesign] Re: CQS
>
> What is missing from your description is that after the domain's state is
> persisted, an event is published from that bounded context.
>
> Another bounded context, the one which handles queries, is subscribed to
> that event and takes the relevant data and saves it in its own schema
> possibly with calculated values.
>
>> So, in this scenario, I should persist the result of one method
>> (order.Total(), for example) in my model so I have it available for
>> querying.
>
> Actually, the data in the event above is what is persisted – it is
> reasonable to assume that the OrderAccepted event would include its total,
> among other things.
>
> --
>
> Udi Dahan - The Software Simplist
>
> From: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Carlos Peix
> Sent: 02 February 2009 23:54
> To: domaindrivendesign@yahoogroups.com
> Subject: RE: [domaindrivendesign] Re: CQS
>
> Hi Udi,
>
> Thanks for your response.
>
> I'm not sure what you are referring to with the "query bounded context" but
> let me explain what I understand from Greg's posts and interview.
>
> We use the "write only" domain model sending commands, then some service,
> the command or the domain itself reacts according to the command an all the
> changes to state get persisted to the data store. Let's say we use
> (N)Hibernate.
>
> Then a query is received and we get the proper DTO from the data store with,
> for example, projections (or any other technique).
>
> I see no bounded context here, unless you consider the projections schema a
> bounded context (which is possible).
>
> So, in this scenario, I should persist the result of one method
> (order.Total(), for example) in my model so I have it available for
> querying.
>
> Is that what you are proposing?
>
> Thanks
>
> Carlos Peix
>
> ________________________________
>
> De: domaindrivendesign@yahoogroups.com
> [mailto:domaindrivendesign@yahoogroups.com] En nombre de Udi Dahan
> Enviado el: Lunes, 02 de Febrero de 2009 07:07 p.m.
> Para: domaindrivendesign@yahoogroups.com
> Asunto: RE: [domaindrivendesign] Re: CQS
>
> Carlos,
>
> In all cases where I needed to show a calculated value, I stored it as well
> (but usually only in the bounded context dealing with queries).
>
> --
> Udi Dahan - The Software Simplist
>
>> -----Original Message-----
>> From: domaindrivendesign@yahoogroups.com
>> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Carlos Peix
>> Sent: 02 February 2009 22:46
>> To: domaindrivendesign@yahoogroups.com
>> Subject: RE: [domaindrivendesign] Re: CQS
>>
>> Hi,
>>
>> I was following this thread and, additionally, I saw the interview to
>> Greg posted a few days ago and I still have some caveats regarding the
>> DTO generation directly from the data store, without mapping objects
>> from the domain model (that is, the Q part of the pattern).
>>
>> One of them is, what if I need on those DTOs a property not present in
>> the data store, for example a calculated property?
>>
>> Thanks
>>
>> Carlos Peix
>>
>> ________________________________
>>
>> De: domaindrivendesign@yahoogroups.com
>> [mailto:domaindrivendesign@yahoogroups.com] En nombre de Udi Dahan
>> Enviado el: Lunes, 02 de Febrero de 2009 10:42 a.m.
>> Para: domaindrivendesign@yahoogroups.com
>> Asunto: RE: [domaindrivendesign] Re: CQS
>>
>>
>>
>> Eben,
>>
>> Auditing needs to understood at two different levels - between
>> services,
>> where it often takes the form of business activity monitoring, and
>> within a service, where it may be done using various techniques (like
>> triggers).
>>
>> In order to come up with a feasible auditing solution, one needs
>> specific requirements, and only then can the utility of various
>> techniques be compared.
>>
>> --
>>
>> Udi Dahan - The Software Simplist
>>
>> From: domaindrivendesign@yahoogroups.com
>> [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eben Roux
>> Sent: 02 February 2009 09:38
>> To: domaindrivendesign@yahoogroups.com
>> Subject: [domaindrivendesign] Re: CQS
>>
>> Hey Udi,
>>
>> "If the command in your example is 'submit order', then that would be
>> copied for the audit trail."
>>
>> Yes, that makes sense and I get it. What I am trying to "get more" is
>> that whole little 'submit order' bit. Does the command-audit save all
>> the data for the command or does it simply save the event with some
>> very pertinent correlation data?
>>
>> Let's say that once the order is accepted the stock service has to
>> receive a 'reduce stock' command so:
>>
>> REDUCE STOCK: Product-DDD, Quantity-1
>>
>> The Stock record contains say, like, 50 fields (hypothetically) so our
>> audit should tell us what happened ('reduce stock') but also just the
>> data that changed --- else to get what exactly happed we have to
>> compare data. In this example the comparison may only involve v1 and
>> v2 of a record, but there may be instance where a whole bunch of data
>> is changed...
>>
>> Anyway, will get to a solution one way or the other.
>>
>> Regards,
>> Eben
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.233 / Virus Database: 270.10.15/1923 - Release Date:
>> 01/02/2009 18:02
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.233 / Virus Database: 270.10.15/1923 - Release Date:
>> 01/02/2009 18:02
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.233 / Virus Database: 270.10.15/1923 - Release Date: 01/02/2009
> 18:02
>
>



--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.