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.
> >
>

Hi Vaughn,

Thanks for your reply. I am just a little confused regarding the code you
posted. If there is a recurring event every Monday from the first day of january
to the last day of july, given it is the first monday of april that query won't
get that recurring event (every monday from january to july). I am sorry if I
wasn't clear enough.

Anyway, I was thinking about this and since I might have thousands of events per
day I won't be able to present the user those events in a calendar. The UI will
show the user the events only for a given day in a screen ordered by hour of
day. So what I was thinking to do is to have 7 different collections in the
calendar where each belongs to a day of week and each time the user creates a
recurring event, the calendar (on the server) will calculate what days that
recurring event applies to and "add" that recurring event to the corresponding
days (in the collections). In the worst case (considering performance) I will
have to "add" the recurring event 7 times (in each collection). Having this in
mind when a user (client) asks the events for monday from a calendar associated
to a specific location (NYC) it will get the precalculated events from the
Monday Collection and that's all.
How do you see this solution?

Regards.

--- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@...>
wrote:
>
> 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 Nuno,

Thanks for your response! That was more or less what I was thinking but solving
the problem not with SQL but with objects, I know the same logic applies so I
really appreciate your contribution.
However, since I realized my UI will show events per day only I thought about
the solution I posted when replying to Vaughn (classifying each recurring event
in a given collection that belongs to a day of week) so feel free to analize
what I post and give me some feedback on what you think about that.

Regards

--- In domaindrivendesign@yahoogroups.com, Nuno Lopes <nbplopes@...> wrote:
>
> One last thing if you haven't got the merge part.
>
> Actual Events need an extra optional attribute. The Id of the "event
recurrence specification".
>
> So for instance, if the user marks a specific event as cancelled, and such
event was planned by the function, it is inserted in the actual event list with
such attribute pointing to the "event recurrence specification".
>
> Then merging becomes trivial.
>
> The relationship between a Recurrance Specification and the Actual Event in
SOM terms is the same as a Item - Specific Item. In DNC terms is Descrption -
Thing.
>
> The core process is actually quite trivial.
>
> Hope it helps.
>
> Nuno
> PS: The F1 function in SQL is just an example. I would use a Factory of
planned events of course given a recurrance specification. Still, nothing but a
function.
>
> On May 23, 2012, at 12:21 AM, vvernon_shiftmethod wrote:
>
> > 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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
>

Eric wrote a report on the summit that took place a few weeks back:

http://dddcommunity.org/events/ddd-summit-2012

Hi all,

I am learning DDD using Eric's book. Is there code sample (ideally C#) for each
pattern described in the book. I know there is a Cargo project. But a detailed
code sample for each pattern would be easier to digest.

May I post questions here that I don't understand from the book?

Thank you!

Hi Ping Pong,

Feel free to ask any question here. Instead of pasting an isolate piece of code
it would be better for you to present us your problem so we can guide you from
there.

Regards

--- In domaindrivendesign@yahoogroups.com, "Ping Pong" <pingpongofkingkong@...>
wrote:
>
> Hi all,
>
> I am learning DDD using Eric's book. Is there code sample (ideally C#) for
each pattern described in the book. I know there is a Cargo project. But a
detailed code sample for each pattern would be easier to digest.
>
> May I post questions here that I don't understand from the book?
>
> Thank you!
>

My upcoming book "Implementing Domain-Driven Design" has 14 chapters of
instruction and code based on a running Core Domain project. The patterns
covered include several of the strategic design patterns and just about all of
the tactical design patterns.

If you follow me on Twitter I will soon be announcing early access on
SafariBooksOnline.com.

Twitter: @VaughnVernon

Vaughn

--- In domaindrivendesign@yahoogroups.com, "Ping Pong" <pingpongofkingkong@...>
wrote:
>
> Hi all,
>
> I am learning DDD using Eric's book. Is there code sample (ideally C#) for
each pattern described in the book. I know there is a Cargo project. But a
detailed code sample for each pattern would be easier to digest.
>
> May I post questions here that I don't understand from the book?
>
> Thank you!
>

Also you will find a big chunk of chapter 10 of my book here:

http://dddcommunity.org/library/vernon_2011

If you like this essay, you are going to love the book.

Vaughn


--- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@...>
wrote:
>
> My upcoming book "Implementing Domain-Driven Design" has 14 chapters of
instruction and code based on a running Core Domain project. The patterns
covered include several of the strategic design patterns and just about all of
the tactical design patterns.
>
> If you follow me on Twitter I will soon be announcing early access on
SafariBooksOnline.com.
>
> Twitter: @VaughnVernon
>
> Vaughn
>
> --- In domaindrivendesign@yahoogroups.com, "Ping Pong" <pingpongofkingkong@>
wrote:
> >
> > Hi all,
> >
> > I am learning DDD using Eric's book. Is there code sample (ideally C#) for
each pattern described in the book. I know there is a Cargo project. But a
detailed code sample for each pattern would be easier to digest.
> >
> > May I post questions here that I don't understand from the book?
> >
> > Thank you!
> >
>

How do you handle the case when you have to notify the UI about the input
errors?

I do DbC by applying preconditions but this way there is no way for me to
collect the error messages. Even if I change the code not to throw exceptions
when it barely breaks the invariant and collect the error messages it becomes
unnatural. Please take into account that I am not considering any Validator
object performing the validations, just the domain objects.
To put an example my code looks like:

Employee.namedAsContactedBy(Name.fromString("John"),
PhoneNumber.fromString("222-3344"));

In that case the VO Name and VO PhoneNumber both throw an exception only if the
string representing the name or the phone is not valid.

If I want to show the user the error messages I cannot use the code above
because if both Name or PhoneNumber are incorrects I will only get 1 error (the
exception thrown for the first property that was checked and failed) so a
possible solution to do this is to do (let's say in the UI Controller):

AssertionResult result = Name.assertValidFrom("John");
result.collectedIn(messageCollector);

result = PhoneNumer.assertValidFrom("222-3322")
result.collectedIn(messageCollector);

messageCollector.getMessages(); // returns the messages that will inform the
user about data input errors

I am using this last solution for FORM input data. Since the class represents
the general Idea it is in a good place of creating its instances and asserting
if a primitive value is valid for its creation.

What other options do we have without validating the request or using
validators?

When will it be published, in paper and pdf?

--- In domaindrivendesign@yahoogroups.com, "vvernon_shiftmethod" <vvernon@...>
wrote:
>
> My upcoming book "Implementing Domain-Driven Design" has 14 chapters of
instruction and code based on a running Core Domain project. The patterns
covered include several of the strategic design patterns and just about all of
the tactical design patterns.
>
> If you follow me on Twitter I will soon be announcing early access on
SafariBooksOnline.com.
>
> Twitter: @VaughnVernon
>
> Vaughn
>
> --- In domaindrivendesign@yahoogroups.com, "Ping Pong" <pingpongofkingkong@>
wrote:
> >
> > Hi all,
> >
> > I am learning DDD using Eric's book. Is there code sample (ideally C#) for
each pattern described in the book. I know there is a Cargo project. But a
detailed code sample for each pattern would be easier to digest.
> >
> > May I post questions here that I don't understand from the book?
> >
> > Thank you!
> >
>

How to deal with requirements which cannot be tied to functional domains ?
http://caminao.wordpress.com/how-to-implement-symbolic-representations/requireme\
nts/non-functional-requirements/

Remy

Java, but You will find also: Events, Sagas, CqRS, BDD:
http://code.google.com/p/ddd-cqrs-sample/

Project contains: over 200 classes, about 50A4 pages in wiki, scalable "map"
that You can click and go straight to the code:
http://prezi.com/hi2dmhfej9zu/ddd-cqrs-sample/


regards
S³awek Sobótka
http://ssepp.pl
http://bottega.com.pl

Based on book review and description, i doubt it is for a beginner. It is a
description of how the author creates a project using DDD and other patterns.

--- In domaindrivendesign@yahoogroups.com, Mohamed RAHIM <math.sipo@...> wrote:
>
> *.NET Domain-Driven Design with C#:
> Problem-Design-Solution*<http://dddpds.codeplex.com/>
>
> http://dddpds.codeplex.com/
>
>
>
> ---------- Forwarded message ----------
> From: SÅ‚awek <slawomir.sobotka@...>
> Date: Fri, Jun 1, 2012 at 6:53 AM
> Subject: [domaindrivendesign] Re: Code Sample for DDD patterns for DDD
> learner
> To: domaindrivendesign@yahoogroups.com
>
>
> **
>
>
> Java, but You will find also: Events, Sagas, CqRS, BDD:
> http://code.google.com/p/ddd-cqrs-sample/
>
> Project contains: over 200 classes, about 50A4 pages in wiki, scalable
> "map" that You can click and go straight to the code:
> http://prezi.com/hi2dmhfej9zu/ddd-cqrs-sample/
>
> regards
> S³awek Sobótka
> http://ssepp.pl
> http://bottega.com.pl
>
>
>
>
>
> --
> Mohamed RAHIM
> LinkedIn : http://www.linkedin.com/in/rahimmed
> Twitter   : @islamath <https://twitter.com/#!/islamath>
>
> Your long term fate may be in danger, Take a moment to seek for your
> salvation!
> Fi Amani ALLAH!
>

Where would you consider various aspects/activities of DDD to fit within the
software architecture and detailed design phases of a development process
(particularly agile)?

I feel like initial modeling of the bounded contexts and core domain (at least
at a high-level) would be an architectural concern?

Any consensus on this?

Thank you.