Hello All,

I wanted to ask the community about their thoughts regarding the preferred
strategy on defining associations in a model.
In my understanding, if an Aggregate Root is being defined then any domain
associations need to defined and accessed only from within the Aggregate Root,
so that the invariant it is maintaining can be satisfied.

But what if the model component is an Entity and not an Aggregate Root and there
is no invariant to be maintained would it make sense to define in the model any
associations that may exist in the domain based solely on the argument that they
are present in the domain?
It is very often the case that too many associations are defined upfront without
us really being able to explain the benefit that those associations bring (apart
from facilitating UI rendering).

Any thoughts?

Cheers,
Savvas

Savvas,

A relationship may exist in the model but not be realized in code, which is
perfectly acceptable.  The model manifests in several forms: the domain-specific
language; box-and-line diagrams; UML; text documentation, code, and many others.
It may be helpful to acknowledge and be mindful of such relationships when
discussing the model with domain experts.  However, if the relationships are not
needed to satisfy business rules in the code, then chances are adding it will
only introduce unnecessary complexity.

Often I find that copying the data from one aggregate to another serves just as
well and offers many advantages over inter-aggregate references and keeps the
code simpler.  The use of events and dedicated read stores also helps avoid
extraneous relationships, since it empowers the various applications to
construct and maintain their own relationships apart from the core business
logic.

Regards,

Jesse


--- In domaindrivendesign@yahoogroups.com, "savvas_andreas_moysidis"
<savvas.andreas.moysidis@...> wrote:
>
> Hello All,
>
> I wanted to ask the community about their thoughts regarding the preferred
strategy on defining associations in a model.
> In my understanding, if an Aggregate Root is being defined then any domain
associations need to defined and accessed only from within the Aggregate Root,
so that the invariant it is maintaining can be satisfied.
>
> But what if the model component is an Entity and not an Aggregate Root and
there is no invariant to be maintained would it make sense to define in the
model any associations that may exist in the domain based solely on the argument
that they are present in the domain?
> It is very often the case that too many associations are defined upfront
without us really being able to explain the benefit that those associations
bring (apart from facilitating UI rendering).
>
> Any thoughts?
>
> Cheers,
> Savvas
>

Skills Matter is pleased to announce the 4th DDD eXchange taking place on June
15th! The annual conference brings together leading experts with 125
practitioners and enthusiasts for an interactive, high energy event.  Join us to
learn and share with the leading designers and developers in DDD. The conference
will be led by Eric Evans who will be speaking on 'Strategic Design and
Established Formalisms'. Other highlights include Greg Young on 'Functional
Programming with DDD', and Hans Dockter on 'Gradle and the Domain Model.' Don't
miss the DDD exchange this June 15th, a truly established date in the DDD
calendar. Read the full programme here!

What: DDD eXchange
When: 15th June 2012
Wherre: Skills Matter, 116-120 Goswell Road, London, EC1V 7DP
Twitter: #dddx
Full Programme and tickets: http://bit.ly/DDDX2012

Is DDD bound to a "Silo" approach, as opposed to SOA's "Peer to Peer"
philosophy.
http://caminao.wordpress.com/engineering/system-engineering-processes/reuse/

Hi Remy,

Regarding the "silo" bit in DDD I blogged this:
http://www.ebenroux.co.za/post/2010/05/27/Silo-where-are-you!.aspx

My take on this is that SOA and DDD operate at different levels.  As anyone with
a little bit of experience should be able to tell there is no "one size fits
all".

So for a particular bounded context you could expose some interactions with the
domain using SOA constructs.

Since we have all been taught from around age 5 that we need high cohesion and
low coupling we can say that DDD BCs are aimed at the high cohesion side of
things and SOA at the low coupling.  This doesn't mean that DDD should be
tightly coupled but talking at a higher level here.

I have come to the conclusion that many of the issues we have in software design
has quite a bit to do with function reachability.  So if I am coding a
particular piece of software and I need to re-use something in another piece of
software just how do I get to it?  One of these perhaps:

- Call a method in my class.
- Call method in another class (DI perhaps).
- Call method in another class in another process (WSI / ESB perhaps).

I reckon a lot of software has failed as a result of the communication problem
between the functions required.  That is why we have seen too many systems
become an uber system that does *everything* so that communication is "easier". 
Then we see systems fail where the functions are teased apart but the
communication between them is so poorly designed that the system grinds to a
halt.

So it definitely is a tricky business and requires careful design that only
comes from experience or grace.

Regards,
Eben

 

If there is orthogonality (like for parallel execution states in StateCharts), x and y are uncorrelated state variables.

 

I don't see how orthogonality could be defined more clearly than with state machines.
Moreover, all terms are very precisely defined, along the pages and in the "reflections for the perplexed".
I'm not making any assumption about your level of understanding but those things are complex and shifts in paradigms are often difficult to comprehend. And confronted to new ideas you shouldn't speak of "someone without a clue who wants to hide their lack of ideas and clarity with obscured terminologies, buzzwords, and stock diagrams".

Hi all,

I know this has been discussed around two years ago but I am looking for a
concrete solution with recurring events involving complex time rules: daily,
weekly, monthly. MS Outlook has a great deductive UI that helps to understand
those rules. It will take place in a shared calendar and high volume. As Vaughn
said in that previous thread the queries are really complex and I don't find any
solution that involves just a query. Having in mind that we store the recurring
event (and not the occurrences because of performance reasons) I see a potential
solution similar to the one described by Martin Fowler in its Recurring document
and doing in memory calculations based on the time expressions of each event.

Any help is appreciated.

Thanks,
Sebastian

Sebastian,

If the events are limited in scope (e.g. a single user viewing a particular day
or month in his or her calendar) then it should be possible to load the events
for the calendar into memory and perform calculations as the user scrolls
through the days/weeks/months.  It might be helpful to precalculate expiration
dates for each event (if applicable;  non-recurring events would expire as of
the event end date, and events that recur indefinitely would have no expiration
date).  The server would then only select events whose start date occurs within
the date range of the current view and whose expiration date is null or occurs
on or after the start date for the current view.  The actual date calculation
logic could also be moved into the client if volume is very high and server
performance is critical.

Regards,
Jesse


--- In domaindrivendesign@yahoogroups.com, "sebaszipp" <sebaszipp@...> wrote:
>
> Hi all,
>
> I know this has been discussed around two years ago but I am looking for a
concrete solution with recurring events involving complex time rules: daily,
weekly, monthly. MS Outlook has a great deductive UI that helps to understand
those rules. It will take place in a shared calendar and high volume. As Vaughn
said in that previous thread the queries are really complex and I don't find any
solution that involves just a query. Having in mind that we store the recurring
event (and not the occurrences because of performance reasons) I see a potential
solution similar to the one described by Martin Fowler in its Recurring document
and doing in memory calculations based on the time expressions of each event.
>
> Any help is appreciated.
>
> Thanks,
> Sebastian
>

Do you need to schedule more than 1000 years in the future?

I don't but considering that it is a shared calendar with maybe 100+ events a
day I see better to have stored the recurring pattern and not the occurrences.

As Sweetlandj said I see a good option evaluating the recurring patterns in the
client with JS and to render the calendar according to that despite it also gets
kind of complex:

If the user selects date 5/5/2012

The JS code should:

1) Call the server to get the first/next 20 recurring events with date range
(from, to) including 5/5/2012
2) Evaluate each recurring event to see if applies for date 5/5/2012 and if it
does render the event in the calendar's day
3) Repeat step 1 and 2 until there are no more recurring events

What if there are 2000 recurring events in total? All of them could match date
5/5/2012. Once the user scrolls down and those 2000 recurring events are
evaluated, then they will be evaluated again for date 6/5/2012.

Another option is to populate the calendar with the recurring event occurrences
in the client but seems killing too.

The most easy option is to populate the calendar in the server with the
recurring event occurrences but what if 50 users schedule a daily event 1 year
from now? This doesn't seem a nice model from a performance perspective. I am
also violating the AR creation rule.

I think there is no perfect solution and a trade off should be thought.

Any ideas?

Thanks,
Sebastian



--- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@...> wrote:
>
> Do you need to schedule more than 1000 years in the future?
> On May 21, 2012 3:35 PM, "sebaszipp" <sebaszipp@...> wrote:
>
> > **
> >
> >
> > Hi all,
> >
> > I know this has been discussed around two years ago but I am looking for a
> > concrete solution with recurring events involving complex time rules:
> > daily, weekly, monthly. MS Outlook has a great deductive UI that helps to
> > understand those rules. It will take place in a shared calendar and high
> > volume. As Vaughn said in that previous thread the queries are really
> > complex and I don't find any solution that involves just a query. Having in
> > mind that we store the recurring event (and not the occurrences because of
> > performance reasons) I see a potential solution similar to the one
> > described by Martin Fowler in its Recurring document and doing in memory
> > calculations based on the time expressions of each event.
> >
> > Any help is appreciated.
> >
> > Thanks,
> > Sebastian
> >
> >
> >
>

Sebastian,

The recurring pattern could also include the date of the first occurrence and
the date of the last occurrence (if bounded).  These could be calculated when
the event is created.  The client would then only select the events whose first
occurrence or last occurrence occur within the date range of the current view (a
single day in your example) which should limit the number of recurring events to
be considered and therefore the number of calculations that need to be
performed.

Another approach would be to store the recurring pattern in an aggregate and the
occurrences themselves in a separate read store.  The next set of occurrences
could be generated periodically via some other process or deleted and
regenerated if the pattern of recurrence changes.  This would simplify the query
logic and eliminate the need for repeatedly performing complex calculations over
similar date ranges.  It is also limited in that if a user is permitted to
browse forward or backward to some arbitrary date the process that generates the
occurrences may not have caught up, so there would need to be constraints around
how far forward or backward a user can navigate.

Regards,
Jesse


--- In domaindrivendesign@yahoogroups.com, "sebaszipp" <sebaszipp@...> wrote:
>
>
> I don't but considering that it is a shared calendar with maybe 100+ events a
day I see better to have stored the recurring pattern and not the occurrences.
>
> As Sweetlandj said I see a good option evaluating the recurring patterns in
the client with JS and to render the calendar according to that despite it also
gets kind of complex:
>
> If the user selects date 5/5/2012
>
> The JS code should:
>
> 1) Call the server to get the first/next 20 recurring events with date range
(from, to) including 5/5/2012
> 2) Evaluate each recurring event to see if applies for date 5/5/2012 and if it
does render the event in the calendar's day
> 3) Repeat step 1 and 2 until there are no more recurring events
>
> What if there are 2000 recurring events in total? All of them could match date
5/5/2012. Once the user scrolls down and those 2000 recurring events are
evaluated, then they will be evaluated again for date 6/5/2012.
>
> Another option is to populate the calendar with the recurring event
occurrences in the client but seems killing too.
>
> The most easy option is to populate the calendar in the server with the
recurring event occurrences but what if 50 users schedule a daily event 1 year
from now? This doesn't seem a nice model from a performance perspective. I am
also violating the AR creation rule.
>
> I think there is no perfect solution and a trade off should be thought.
>
> Any ideas?
>
> Thanks,
> Sebastian
>
>
>
> --- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@> wrote:
> >
> > Do you need to schedule more than 1000 years in the future?
> > On May 21, 2012 3:35 PM, "sebaszipp" <sebaszipp@> wrote:
> >
> > > **
> > >
> > >
> > > Hi all,
> > >
> > > I know this has been discussed around two years ago but I am looking for a
> > > concrete solution with recurring events involving complex time rules:
> > > daily, weekly, monthly. MS Outlook has a great deductive UI that helps to
> > > understand those rules. It will take place in a shared calendar and high
> > > volume. As Vaughn said in that previous thread the queries are really
> > > complex and I don't find any solution that involves just a query. Having
in
> > > mind that we store the recurring event (and not the occurrences because of
> > > performance reasons) I see a potential solution similar to the one
> > > described by Martin Fowler in its Recurring document and doing in memory
> > > calculations based on the time expressions of each event.
> > >
> > > Any help is appreciated.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > >
> > >
> >
>

Hi sweetlandj,

What you said in your first paragraph is what I meant before. Suppose there are
2000 events whose first and last occurrence is within the date range of the view
and only the last 10 events occurs on a given date. The client will perform 100
of 20 elements queries and evaluate each event when only the last 20 events will
match the view.
I thought about writing an Iterator with some kind of pattern recognition and
still thinking.
Regarding the other paragraph you wrote, is the best way to have precalculated
the occurrences but I was thinking about doing it lazy because of performance
reasons.

Thanks!

--- In domaindrivendesign@yahoogroups.com, "sweetlandj" <sweetlandj@...> wrote:
>
> Sebastian,
>
> The recurring pattern could also include the date of the first occurrence and
the date of the last occurrence (if bounded).  These could be calculated when
the event is created.  The client would then only select the events whose first
occurrence or last occurrence occur within the date range of the current view (a
single day in your example) which should limit the number of recurring events to
be considered and therefore the number of calculations that need to be
performed.
>
> Another approach would be to store the recurring pattern in an aggregate and
the occurrences themselves in a separate read store.  The next set of
occurrences could be generated periodically via some other process or deleted
and regenerated if the pattern of recurrence changes.  This would simplify the
query logic and eliminate the need for repeatedly performing complex
calculations over similar date ranges.  It is also limited in that if a user is
permitted to browse forward or backward to some arbitrary date the process that
generates the occurrences may not have caught up, so there would need to be
constraints around how far forward or backward a user can navigate.
>
> Regards,
> Jesse
>
>
> --- In domaindrivendesign@yahoogroups.com, "sebaszipp" <sebaszipp@> wrote:
> >
> >
> > I don't but considering that it is a shared calendar with maybe 100+ events
a day I see better to have stored the recurring pattern and not the occurrences.
> >
> > As Sweetlandj said I see a good option evaluating the recurring patterns in
the client with JS and to render the calendar according to that despite it also
gets kind of complex:
> >
> > If the user selects date 5/5/2012
> >
> > The JS code should:
> >
> > 1) Call the server to get the first/next 20 recurring events with date range
(from, to) including 5/5/2012
> > 2) Evaluate each recurring event to see if applies for date 5/5/2012 and if
it does render the event in the calendar's day
> > 3) Repeat step 1 and 2 until there are no more recurring events
> >
> > What if there are 2000 recurring events in total? All of them could match
date 5/5/2012. Once the user scrolls down and those 2000 recurring events are
evaluated, then they will be evaluated again for date 6/5/2012.
> >
> > Another option is to populate the calendar with the recurring event
occurrences in the client but seems killing too.
> >
> > The most easy option is to populate the calendar in the server with the
recurring event occurrences but what if 50 users schedule a daily event 1 year
from now? This doesn't seem a nice model from a performance perspective. I am
also violating the AR creation rule.
> >
> > I think there is no perfect solution and a trade off should be thought.
> >
> > Any ideas?
> >
> > Thanks,
> > Sebastian
> >
> >
> >
> > --- In domaindrivendesign@yahoogroups.com, Greg Young <gregoryyoung1@>
wrote:
> > >
> > > Do you need to schedule more than 1000 years in the future?
> > > On May 21, 2012 3:35 PM, "sebaszipp" <sebaszipp@> wrote:
> > >
> > > > **
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > I know this has been discussed around two years ago but I am looking for
a
> > > > concrete solution with recurring events involving complex time rules:
> > > > daily, weekly, monthly. MS Outlook has a great deductive UI that helps
to
> > > > understand those rules. It will take place in a shared calendar and high
> > > > volume. As Vaughn said in that previous thread the queries are really
> > > > complex and I don't find any solution that involves just a query. Having
in
> > > > mind that we store the recurring event (and not the occurrences because
of
> > > > performance reasons) I see a potential solution similar to the one
> > > > described by Martin Fowler in its Recurring document and doing in memory
> > > > calculations based on the time expressions of each event.
> > > >
> > > > Any help is appreciated.
> > > >
> > > > Thanks,
> > > > Sebastian
> > > >
> > > >
> > > >
> > >
> >
>

Recently I joined a new company which is a travel company, they have an old asp
system. I have been asked to develop a .net application to replace the old asp
system. which I come across try to use DDD. This is the first time I am
implementing apps using DDD.

I have read the book of Jimmy Nilsson "Applying Domain Driven Design and
Patterns". I also downloaded the sample C# program about the cargo tracking. It
really confused me about the relation between application services (SOA ??),
Domain Service (Services in Eric Evan[DDD]), repositories and entities. I have
the following question to ask(hopefully you guys can help me because I don't
have a person to ask these questions):

1. Should the entity knows about the repositories? To do CRUD operations?

2 What is the domain services, first i thought they should handle domain
business logic and algorithm. But it seem that from Jimmy's book the domain
service can do CRUD operations as well. And also Entities can refer it as well.

3 if entities that know about repositories and domain services, is that kind of
messed up the entities as a object itself?

4 From the sample cargo project, should application service knows about
repositories? Is that kind cross layer reference?

5 where should the transaction be handled in the application service layer?

Those question keep confuse me. I tried to ask some developers, but seems
everyone has a different idea.

Hopefully you guys can help me with those questions

Thanks a lot.

Hi

From my experience with software, there are very few cases where there's a
single correct approach to a problem, and you will probably get several opinions
in this group alone. Nevertheless, I would like to offer my two cents on your
questions:

1. Should the entity knows about the repositories? To do CRUD operations?

As I said, you will get mixed opinions on that subject. I believe that the
domain model should be as separated as possible from the infrastructure, which
means that entities are not injected with repositories, but rather the
repository knows about the domain model and is accessed from services.
Also, repositories should offer more to your domain than simply provide an
interface to CRUD operations. Think about your ubiquitous language - I'm pretty
positive that your domain experts don't "Delete" a reservation, but rather
"Cancel" it. Vacation packages are probably not "Created", but rather assembled
from Flights, Hotels, Attractions, and Tours. Try to first think what kind of
data is required by your domain model functionality - and derive your repository
interface from there, rather than automatically expose CRUD operations.

2 What is the domain services, first i thought they should handle domain
business logic and algorithm. But it seem that from Jimmy's book the domain
service can do CRUD operations as well. And also Entities can refer it as well.

Domain Services handle domain business logic which does not belong in a single
object (be it an entity or a value-object). So whenever you need to implement
logic that require information or logic of several objects, implement that
logic, or call sequence, in a domain service.
I don't exactly remember how JN used services for CRUD operations, but that is
the responsibility of the repositories (with the side notes about CRUD from the
previous paragraph). Again, I think that services should not be called from
within the domain model, but rather the other way around, but that is open to
interpretation and personal taste.

3 if entities that know about repositories and domain services, is that kind of
messed up the entities as a object itself?

As I mentioned, I believe that they shouldn't know about repos and services.

4 From the sample cargo project, should application service knows about
repositories? Is that kind cross layer reference?
5 where should the transaction be handled in the application service layer?

Most of the time, the answer would be yes. The application service is where you
handle your transactions and session logic, so you would often call repositories
for queries (if not using CQRS) or commit them (repository.Save()). In some
cases you will call repositories from your service to add entities
(VacationPackagesrepository.AddVacationPackage(aVacationPackage);), but most
modern ORMs will help you achieve this from within the domain model without
calling the repository explicitly, like this:

VacationPackage package =
_vacationPacakgeFactory.CreateVacationPacakage(flight,hotel);
travelAgencyBranch.OfferPackage(package);

The call to OfferPackage might add the package argument to an internal list,
managed by the ORM, which will in turn, after saving changes, will both add the
appropriate row to the packages table, and update foreign keys where needed.

Hope that this gives you some direction. Now how about a discount for my next
vacation? ;-)

Cheers,
Moran





--- In domaindrivendesign@yahoogroups.com, "tiger_lu_hao" <tigerhaolu727@...>
wrote:
>
> Recently I joined a new company which is a travel company, they have an old
asp system. I have been asked to develop a .net application to replace the old
asp system. which I come across try to use DDD. This is the first time I am
implementing apps using DDD.
>
> I have read the book of Jimmy Nilsson "Applying Domain Driven Design and
Patterns". I also downloaded the sample C# program about the cargo tracking. It
really confused me about the relation between application services (SOA ??),
Domain Service (Services in Eric Evan[DDD]), repositories and entities. I have
the following question to ask(hopefully you guys can help me because I don't
have a person to ask these questions):
>
> 1. Should the entity knows about the repositories? To do CRUD operations?
>
> 2 What is the domain services, first i thought they should handle domain
business logic and algorithm. But it seem that from Jimmy's book the domain
service can do CRUD operations as well. And also Entities can refer it as well.
>
> 3 if entities that know about repositories and domain services, is that kind
of messed up the entities as a object itself?
>
> 4 From the sample cargo project, should application service knows about
repositories? Is that kind cross layer reference?
>
> 5 where should the transaction be handled in the application service layer?
>
> Those question keep confuse me. I tried to ask some developers, but seems
everyone has a different idea.
>
> Hopefully you guys can help me with those questions
>
> Thanks a lot.
>

If you have a recurring event you can still use a TimeSpan to model the
begins and ends dates, but the ends would be some date far in the future
that your software will never have to actually support. I am kinda sure
that's what Greg meant by a date 1,000 years from now. You'd still mark
the event as recurring so you don't use the ends date as if it is really
the actual end date. Yet, the far future ends will allow you to query
for all recurring events that span a day, week, month, etc.

Assuming that, this repository finder would work:

      @Override
      @SuppressWarnings("unchecked")
      public Collection<CalendarEntry> overlappingCalendarEntries(TenantId
aTenantId, CalendarId aCalendarId, TimeSpan aTimeSpan) {
          Query query =
              this.session().createQuery(
                  "from CalendarEntry as _obj_ " +
                  "where _obj_.tenantId = :tenantId and _obj_.calendarId =
:calendarId and " +
                      "((_obj_.repetition.timeSpan.begins between :tsb and
:tse) or " +
                      " (_obj_.repetition.timeSpan.ends between :tsb and
:tse))");

          query.setParameter("tenantId", aTenantId);
          query.setParameter("calendarId", aCalendarId);
          query.setParameter("tsb", aTimeSpan.begins(), Hibernate.DATE);
          query.setParameter("tse", aTimeSpan.ends(), Hibernate.DATE);

          return (Collection<CalendarEntry>) query.list();
      }

HTH,

Vaughn


--- In domaindrivendesign@yahoogroups.com, "sebaszipp" <sebaszipp@...>
wrote:
>
>
> I don't but considering that it is a shared calendar with maybe 100+
events a day I see better to have stored the recurring pattern and not
the occurrences.
>
> As Sweetlandj said I see a good option evaluating the recurring
patterns in the client with JS and to render the calendar according to
that despite it also gets kind of complex:
>
> If the user selects date 5/5/2012
>
> The JS code should:
>
> 1) Call the server to get the first/next 20 recurring events with date
range (from, to) including 5/5/2012
> 2) Evaluate each recurring event to see if applies for date 5/5/2012
and if it does render the event in the calendar's day
> 3) Repeat step 1 and 2 until there are no more recurring events
>
> What if there are 2000 recurring events in total? All of them could
match date 5/5/2012. Once the user scrolls down and those 2000 recurring
events are evaluated, then they will be evaluated again for date
6/5/2012.
>
> Another option is to populate the calendar with the recurring event
occurrences in the client but seems killing too.
>
> The most easy option is to populate the calendar in the server with
the recurring event occurrences but what if 50 users schedule a daily
event 1 year from now? This doesn't seem a nice model from a performance
perspective. I am also violating the AR creation rule.
>
> I think there is no perfect solution and a trade off should be
thought.
>
> Any ideas?
>
> Thanks,
> Sebastian
>
>
>
> --- In domaindrivendesign@yahoogroups.com, Greg Young gregoryyoung1@
wrote:
> >
> > Do you need to schedule more than 1000 years in the future?
> > On May 21, 2012 3:35 PM, "sebaszipp" sebaszipp@ wrote:
> >
> > > **
> > >
> > >
> > > Hi all,
> > >
> > > I know this has been discussed around two years ago but I am
looking for a
> > > concrete solution with recurring events involving complex time
rules:
> > > daily, weekly, monthly. MS Outlook has a great deductive UI that
helps to
> > > understand those rules. It will take place in a shared calendar
and high
> > > volume. As Vaughn said in that previous thread the queries are
really
> > > complex and I don't find any solution that involves just a query.
Having in
> > > mind that we store the recurring event (and not the occurrences
because of
> > > performance reasons) I see a potential solution similar to the one
> > > described by Martin Fowler in its Recurring document and doing in
memory
> > > calculations based on the time expressions of each event.
> > >
> > > Any help is appreciated.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > >
> > >
> >
>

Hi,
I'm replying through the group because I wasn't able to reply directly for some
reason...

Yup, you're on the right track.
Try to make your domain layer as expressive as possible, with relevant logic
implemented within entities and value-object, and only put logic that isn't
related to a single object in a domain service (note the difference between a
domain service and an application service – domain services are part of the
domain model and are expressed using the ubiquitous language, while application
service coordinate application-wide logic).

Cheers,
Moran


From: tigerhaolu727
Sent: Wednesday, May 23, 2012 5:15 AM
To: moranlf
Subject: Re: Questions : Relation between SOA, Domain Service, Repositories and
Entities

Hi Moran

I tried to reply this early this morning, but it doesn't allow me to do that.

Thanks a lot for replying me back. Really appreciated.

The questions was actually come from the AnemicDomainModel from Martin Fowler. I
read it again today with your reply I think I mixed up my domain service with
the service that in the Anemic Domain Model, cuz they both on top of the domain
but my domain service was handling event and service that does not belongs to
any entity and the service in the Anemic Domain Model is handling everything
between entities even the action should be handled by aggregate root (Correct me
if I am wrong here). I think I am on the correct design.

Again, thanks a lot. Those questions really confused me.

For the discount, if I can stay long in this company(hopefully), I am sure I can
find some special offer for you.

--- In domaindrivendesign@yahoogroups.com, "moranlf" <moranlf@...> wrote:
>
>
>
>
>
>
>
>
>
>
> Hi
>
> From my experience with software, there are very few cases where there's a
single correct approach to a problem, and you will probably get several opinions
in this group alone. Nevertheless, I would like to offer my two cents on your
questions:
>
> 1. Should the entity knows about the repositories? To do CRUD operations?
>
> As I said, you will get mixed opinions on that subject. I believe that the
domain model should be as separated as possible from the infrastructure, which
means that entities are not injected with repositories, but rather the
repository knows about the domain model and is accessed from services.
> Also, repositories should offer more to your domain than simply provide an
interface to CRUD operations. Think about your ubiquitous language - I'm pretty
positive that your domain experts don't "Delete" a reservation, but rather
"Cancel" it. Vacation packages are probably not "Created", but rather assembled
from Flights, Hotels, Attractions, and Tours. Try to first think what kind of
data is required by your domain model functionality - and derive your repository
interface from there, rather than automatically expose CRUD operations.
>
> 2 What is the domain services, first i thought they should handle domain
business logic and algorithm. But it seem that from Jimmy's book the domain
service can do CRUD operations as well. And also Entities can refer it as well.
>
> Domain Services handle domain business logic which does not belong in a single
object (be it an entity or a value-object). So whenever you need to implement
logic that require information or logic of several objects, implement that
logic, or call sequence, in a domain service.
> I don't exactly remember how JN used services for CRUD operations, but that is
the responsibility of the repositories (with the side notes about CRUD from the
previous paragraph). Again, I think that services should not be called from
within the domain model, but rather the other way around, but that is open to
interpretation and personal taste.
>
> 3 if entities that know about repositories and domain services, is that kind
of messed up the entities as a object itself?
>
> As I mentioned, I believe that they shouldn't know about repos and services.
>
> 4 From the sample cargo project, should application service knows about
repositories? Is that kind cross layer reference?
> 5 where should the transaction be handled in the application service layer?
>
> Most of the time, the answer would be yes. The application service is where
you handle your transactions and session logic, so you would often call
repositories for queries (if not using CQRS) or commit them (repository.Save()).
In some cases you will call repositories from your service to add entities
(VacationPackagesrepository.AddVacationPackage(aVacationPackage);), but most
modern ORMs will help you achieve this from within the domain model without
calling the repository explicitly, like this:
>
> VacationPackage package =
_vacationPacakgeFactory.CreateVacationPacakage(flight,hotel);
> travelAgencyBranch.OfferPackage(package);
>
> The call to OfferPackage might add the package argument to an internal list,
managed by the ORM, which will in turn, after saving changes, will both add the
appropriate row to the packages table, and update foreign keys where needed.
>
> Hope that this gives you some direction. Now how about a discount for my next
vacation? ;-)
>
> Cheers,
> Moran
>
>
>
>
>
> --- In domaindrivendesign@yahoogroups.com, "tiger_lu_hao" <tigerhaolu727@>
wrote:
> >
> > Recently I joined a new company which is a travel company, they have an old
asp system. I have been asked to develop a .net application to replace the old
asp system. which I come across try to use DDD. This is the first time I am
implementing apps using DDD.
> >
> > I have read the book of Jimmy Nilsson "Applying Domain Driven Design and
Patterns". I also downloaded the sample C# program about the cargo tracking. It
really confused me about the relation between application services (SOA ??),
Domain Service (Services in Eric Evan[DDD]), repositories and entities. I have
the following question to ask(hopefully you guys can help me because I don't
have a person to ask these questions):
> >
> > 1. Should the entity knows about the repositories? To do CRUD operations?
> >
> > 2 What is the domain services, first i thought they should handle domain
business logic and algorithm. But it seem that from Jimmy's book the domain
service can do CRUD operations as well. And also Entities can refer it as well.
> >
> > 3 if entities that know about repositories and domain services, is that kind
of messed up the entities as a object itself?
> >
> > 4 From the sample cargo project, should application service knows about
repositories? Is that kind cross layer reference?
> >
> > 5 where should the transaction be handled in the application service layer?
> >
> > Those question keep confuse me. I tried to ask some developers, but seems
everyone has a different idea.
> >
> > Hopefully you guys can help me with those questions
> >
> > Thanks a lot.
> >
>