Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

domaindrivendesign · Domain-Driven Design

The Yahoo! Groups Product Blog

Check it out!

Group Information

  • Members: 4075
  • Category: Software
  • Founded: Sep 27, 2002
  • Language: English
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 23056 - 23085 of 24078   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#23056 From: "savvas_andreas_moysidis" <savvas.andreas.moysidis@...>
Date: Thu May 10, 2012 5:00 pm
Subject: Defining Associations
savvas_andre...
Send Email Send Email
 
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

#23057 From: "sweetlandj" <sweetlandj@...>
Date: Sat May 12, 2012 1:03 am
Subject: Re: Defining Associations
sweetlandj
Send Email Send Email
 
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
>

#23058 From: "Skills" <skillsmatter@...>
Date: Thu May 17, 2012 10:50 am
Subject: The 4th Annual DDD eXchange // Join us on June 15th!
skills.matter
Send Email Send Email
 
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

#23059 From: "remyfannader" <caminao@...>
Date: Sun May 20, 2012 4:24 am
Subject: The Economics of Reuse: DDD vs SOA
remyfannader
Send Email Send Email
 
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/

#23060 From: Greg Young <gregoryyoung1@...>
Date: Sun May 20, 2012 8:04 am
Subject: Re: The Economics of Reuse: DDD vs SOA
gumboismadeo...
Send Email Send Email
 
This question seems to be based on a misguided idea that SOA and DDD are mutually exclusive.

On Sat, May 19, 2012 at 9:24 PM, remyfannader <caminao@...> wrote:
 

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/




--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

#23061 From: Remy Fannader <caminao@...>
Date: Sun May 20, 2012 8:08 am
Subject: Re: The Economics of Reuse: DDD vs SOA
remyfannader
Send Email Send Email
 
That's the point to discuss ...

#23062 From: Greg Young <gregoryyoung1@...>
Date: Sun May 20, 2012 11:03 pm
Subject: Re: The Economics of Reuse: DDD vs SOA
gumboismadeo...
Send Email Send Email
 
I believe they have long ago been shown even if not formally to be orthogonal (and even complimentary). Many are doing DDD/SOA/EDA on this list as an example.

I have a very hard time reading your article as it seems to use quite arbitrary definitions for things.

" It must be noted that, contrary to misleading similarities, refactoring is the opposite of reuse: instead of building from well understood and safe artifacts, it tries to extract some reusable chunks from opaque and unsafe components. "

Clicking through on refactoring gives a definition I think anyone who has heard the word used would be very confused by.  If for instance you were to have a definition remotely close to  http://en.wikipedia.org/wiki/Code_refactoring  which I would consider a more common definition the sentence reads quite oddly.

Maybe you can write in dumbed down terms the issues that lead you to believe that SOA and DDD are in conflict to each other?

On Sun, May 20, 2012 at 1:08 AM, Remy Fannader <caminao@...> wrote:
 

That's the point to discuss ...




--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

#23063 From: Remy Fannader <caminao@...>
Date: Mon May 21, 2012 4:06 am
Subject: Re: The Economics of Reuse: DDD vs SOA
remyfannader
Send Email Send Email
 
Greg,
I don't think SOA and DDD are in conflict, rather, as you say, orthogonal.
As for "refactoring", the article is titled "legacy refactoring", and the text is clear about the intended meaning, which is not the one you cited from Wikipedia.
Remy.

#23064 From: "eben_roux" <me@...>
Date: Mon May 21, 2012 4:29 am
Subject: Re: The Economics of Reuse: DDD vs SOA
eben_roux
Send Email Send Email
 
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

#23065 From: Greg Young <gregoryyoung1@...>
Date: Mon May 21, 2012 5:44 am
Subject: Re: The Economics of Reuse: DDD vs SOA
gumboismadeo...
Send Email Send Email
 
" Is DDD bound to a "Silo" approach, as opposed to SOA's "Peer to Peer" philosophy. "

" I don't think SOA and DDD are in conflict, rather, as you say, orthogonal."

If they are orthogonal how can one be bound to one approach and another a different approach? To say they are bound means forced to that approach. To say that they are orthogonal means that they are not related (if curves, they do not have a point of intersection). If they are orthogonal how can they be bound to opposing philosophies? These two sentences do not work well together.

Maybe you can explain in dumb language (for people like me) what exactly the issues you are coming up with are?



On Sun, May 20, 2012 at 9:06 PM, Remy Fannader <caminao@...> wrote:
 

Greg,
I don't think SOA and DDD are in conflict, rather, as you say, orthogonal.
As for "refactoring", the article is titled "legacy refactoring", and the text is clear about the intended meaning, which is not the one you cited from Wikipedia.
Remy.




--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

#23066 From: Remy Fannader <caminao@...>
Date: Mon May 21, 2012 6:02 am
Subject: Re: The Economics of Reuse: DDD vs SOA
remyfannader
Send Email Send Email
 
Geometry is not limited to 2D.
Remy.

#23067 From: Greg Young <gregoryyoung1@...>
Date: Mon May 21, 2012 6:28 am
Subject: Re: The Economics of Reuse: DDD vs SOA
gumboismadeo...
Send Email Send Email
 
Let's try again if ddd forces me to x and soa forces me to y and soa and ddd can be applied at the same time... Do I x or y when doing both?


On Monday, May 21, 2012, Remy Fannader wrote:
 

Geometry is not limited to 2D.
Remy.



--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

#23068 From: Remy Fannader <caminao@...>
Date: Mon May 21, 2012 8:31 am
Subject: Re: The Economics of Reuse: DDD vs SOA
remyfannader
Send Email Send Email
 
If there is orthogonality (like for parallel execution states in StateCharts), x and y are uncorrelated state variables.

#23069 From: Greg Young <gregoryyoung1@...>
Date: Mon May 21, 2012 8:48 am
Subject: Re: The Economics of Reuse: DDD vs SOA
gumboismadeo...
Send Email Send Email
 
Using the word versus would make them by definition correlated (noone cares about dinner versus paying taxes unless they are in some way correlated). Again maybe you should try explaining your ideas in dumb language. I am not discounting your ideas I am asking you to better explain them for the fourth time now. Maybe I'm just too dumb to parse all of your ultra intelligent word craftery but it reads like a masters thesis of someone without a clue who wants to hide their lack of ideas and clarity with obscured terminologies, buzzwords, and stock diagrams. If there is a real point to be made why can't it be made simply?

On Monday, May 21, 2012, Remy Fannader wrote:
 

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



--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

#23070 From: Remy Fannader <caminao@...>
Date: Mon May 21, 2012 9:17 am
Subject: Re: The Economics of Reuse: DDD vs SOA
remyfannader
Send Email Send Email
 
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".

#23071 From: Greg Young <gregoryyoung1@...>
Date: Mon May 21, 2012 9:29 am
Subject: Re: The Economics of Reuse: DDD vs SOA
gumboismadeo...
Send Email Send Email
 
I shouldn't have to click through 30 pages to understand your redefinition of words such as refactoring. Anyways this is a waste of time. Best of luck.

On Monday, May 21, 2012, Remy Fannader wrote:
 

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



--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

#23072 From: Remy Fannader <caminao@...>
Date: Mon May 21, 2012 9:34 am
Subject: Re: The Economics of Reuse: DDD vs SOA
remyfannader
Send Email Send Email
 
As far as I'm concerned those discussions, including corrections, are very beneficial and I would really appreciate any suggestion regarding dual definitions that should be added to the aforementioned list.

#23073 From: "sebaszipp" <sebaszipp@...>
Date: Mon May 21, 2012 1:35 pm
Subject: Calendar with recurring events
sebaszipp
Send Email Send Email
 
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

#23074 From: "sweetlandj" <sweetlandj@...>
Date: Mon May 21, 2012 2:32 pm
Subject: Re: Calendar with recurring events
sweetlandj
Send Email Send Email
 
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
>

#23075 From: Greg Young <gregoryyoung1@...>
Date: Tue May 22, 2012 5:54 am
Subject: Re: Calendar with recurring events
gumboismadeo...
Send Email Send Email
 

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


#23076 From: "sebaszipp" <sebaszipp@...>
Date: Tue May 22, 2012 1:16 pm
Subject: Re: Calendar with recurring events
sebaszipp
Send Email Send Email
 
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
> >
> >
> >
>

#23077 From: "sweetlandj" <sweetlandj@...>
Date: Tue May 22, 2012 1:47 pm
Subject: Re: Calendar with recurring events
sweetlandj
Send Email Send Email
 
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
> > >
> > >
> > >
> >
>

#23078 From: "sebaszipp" <sebaszipp@...>
Date: Tue May 22, 2012 5:46 pm
Subject: Re: Calendar with recurring events
sebaszipp
Send Email Send Email
 
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
> > > >
> > > >
> > > >
> > >
> >
>

#23079 From: "tiger_lu_hao" <tigerhaolu727@...>
Date: Tue May 22, 2012 1:51 am
Subject: Questions : Relation between SOA, Domain Service, Repositories and Entities
tiger_lu_hao
Send Email Send Email
 
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.

#23080 From: "moranlf" <moranlf@...>
Date: Tue May 22, 2012 9:46 pm
Subject: Re: Questions : Relation between SOA, Domain Service, Repositories and Entities
moranlf
Send Email Send Email
 
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.
>

#23081 From: "vvernon_shiftmethod" <vvernon@...>
Date: Tue May 22, 2012 11:21 pm
Subject: Re: Calendar with recurring events
vvernon_shif...
Send Email Send Email
 
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
> > >
> > >
> > >
> >
>

#23082 From: Ryan Barrett <ryan@...>
Date: Tue May 22, 2012 9:08 pm
Subject: Re: Questions : Relation between SOA, Domain Service, Repositories and Entities
ryan_b_1753
Send Email Send Email
 
If you've got a CRUD / database style background then I'd recommend that you first read the first sections of PoEAA (focusing on Table and Domain models) and then implement a small DDD application.

It's a different way of thinking, and takes some time to fully grasp, so it's best to contain the newbie mistakes to a small part of the system.

To answer your questions:

1. No.

2. The canonical example is a notification service: you model the idea of notifying people into your domain, and you implement it as a service (i.e. smtp, sms, send-a-letter).  This could be a wrapper to an API call, or an RPC to existing SOA services.  Often you'll be able to use Domain Events to integrate cleanly with your domain model.

3. They don't.  Entities can know of Services, Repositories know of Entities.  That's it.

4.  Yeah, the Services Layer uses Repositories to load instances of Entities from persistent storage.  The also allow searching of the storage for entities (which, imho, breaks SoC).

5. That depends on how you've modelled your domain, and on your choice of persistence layer.  If you can achieve correct results with the transaction being controlled by the Repository than that's great.  In practise, though, I've often had to settle for service-level transactions, with help from the Unit of Work pattern.

-- 
Ryan

On 22 May 2012 03:51, 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.



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/domaindrivendesign/

<*> Your email settings:
   Individual Email | Traditional

<*> To change settings online go to:
   http://groups.yahoo.com/group/domaindrivendesign/join
   (Yahoo! ID required)

<*> To change settings via email:
   domaindrivendesign-digest@yahoogroups.com
   domaindrivendesign-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
   domaindrivendesign-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
   http://docs.yahoo.com/info/terms/



#23083 From: "Moran Lefler" <moranlf@...>
Date: Wed May 23, 2012 6:29 am
Subject: Re: Questions : Relation between SOA, Domain Service, Repositories and Entities
moranlf
Send Email Send Email
 
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.
> >
>

#23084 From: Nuno Lopes <nbplopes@...>
Date: Wed May 23, 2012 11:23 am
Subject: Re: Calendar with recurring events
nbplopes
Send Email Send Email
 
Hi,

F1) Create a function that generate a list of planned occurrences given a start date, end date and occurrence type (daily, weekly and so on).
F2) Create a function that given a start date and end date returns a list of actual occurrences.

If you want to select all occurrences between an interval

1) For each occurrence specification call function F1. An occurrence specification contains start date, end date and type. It may have more attributes.
2) Call function F2

Merge.

You can create a sliding window over the time spam.


Example of F1 in SQL:

CREATE OR REPLACE FUNCTION  generate_recurrences(
    recurs RECURRENCE, 
    start_date DATE,
    end_date DATE
)
    RETURNS setof DATE
    LANGUAGE plpgsql IMMUTABLE
    AS $BODY$
DECLARE
    next_date DATE := start_date;
    duration  INTERVAL;
    day       INTERVAL;
    check     TEXT;
BEGIN
    IF recurs = 'none' THEN
        -- Only one date ever.
        RETURN next next_date;
    ELSIF recurs = 'weekly' THEN
        duration := '7 days'::interval;
        WHILE next_date <= end_date LOOP
            RETURN NEXT next_date;
            next_date := next_date + duration;
        END LOOP;
    ELSIF recurs = 'daily' THEN
        duration := '1 day'::interval;
        WHILE next_date <= end_date LOOP
            RETURN NEXT next_date;
            next_date := next_date + duration;
        END LOOP;
    ELSIF recurs = 'monthly' THEN
        duration := '27 days'::interval;
        day      := '1 day'::interval;
        check    := to_char(start_date, 'DD');
        WHILE next_date <= end_date LOOP
            RETURN NEXT next_date;
            next_date := next_date + duration;
            WHILE to_char(next_date, 'DD') <> check LOOP
                next_date := next_date + day;
            END LOOP;
        END LOOP;
    ELSE
        -- Someone needs to update this function, methinks.
        RAISE EXCEPTION 'Recurrence % not supported by generate_recurrences()', recurs;
    END IF;
END;



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



#23085 From: Nuno Lopes <nbplopes@...>
Date: Wed May 23, 2012 5:16 pm
Subject: Re: Calendar with recurring events
nbplopes
Send Email Send Email
 
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
> > >
> > >
> > >
> >
>



Messages 23056 - 23085 of 24078   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help