gmane.comp.programming.domain-driven-design

Re: Calendar with recurring events

Nuno Lopes — 2012-05-23T17:16:05

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:

Re: Calendar with recurring events

Nuno Lopes — 2012-05-23T11:23:50

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:

Re: Questions : Relation between SOA, Domain Service, Repositories and Entities

Moran Lefler — 2012-05-23T06:29:13

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< at >yahoogroups.com, "moranlf" <moranlf< at >...> wrote:



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

Re: Questions : Relation between SOA, Domain Service, Repositories and Entities

Ryan Barrett — 2012-05-22T21:08:27

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.

Re: Calendar with recurring events

vvernon_shiftmethod — 2012-05-22T23:21:45

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:

     < at >Override
     < at >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< at >yahoogroups.com, "sebaszipp" <sebaszipp< at >...>
wrote:
events a day I see better to have stored the recurring pattern and not
the occurrences.
patterns in the client with JS and to render the calendar according to
that despite it also gets kind of complex:
range (from, to) including 5/5/2012
and if it does render the event in the calendar's day
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.
occurrences in the client but seems killing too.
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.
thought.
wrote:
looking for a
rules:
helps to
and high
really
Having in
because of
memory




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

Re: Questions : Relation between SOA, Domain Service, Repositories and Entities

moranlf — 2012-05-22T21:46:10









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< at >yahoogroups.com, "tiger_lu_hao" <tigerhaolu727< at >...> wrote:



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

Questions : Relation between SOA, Domain Service, Repositories and Entities

tiger_lu_hao — 2012-05-22T01:51:09

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.

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

Re: Calendar with recurring events

sebaszipp — 2012-05-22T17:46:21

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< at >yahoogroups.com, "sweetlandj" <sweetlandj< at >...> wrote:




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

Re: Calendar with recurring events

sweetlandj — 2012-05-22T13:47:39

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< at >yahoogroups.com, "sebaszipp" <sebaszipp< at >...> wrote:




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

Re: Calendar with recurring events

sebaszipp — 2012-05-22T13:16:52

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< at >yahoogroups.com, Greg Young <gregoryyoung1< at >...> wrote:




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

Re: Calendar with recurring events

Greg Young — 2012-05-22T05:54:02

Do you need to schedule more than 1000 years in the future?
On May 21, 2012 3:35 PM, "sebaszipp" <sebaszipp< at >yahoo.com> wrote:

Re: Calendar with recurring events

sweetlandj — 2012-05-21T14:32:43

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

Regards,
Jesse


--- In domaindrivendesign< at >yahoogroups.com, "sebaszipp" <sebaszipp< at >...> wrote:



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

Calendar with recurring events

sebaszipp — 2012-05-21T13:35:30

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



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

Re: The Economics of Reuse: DDD vs SOA

Remy Fannader — 2012-05-21T09:34:48

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.

Re: The Economics of Reuse: DDD vs SOA

Greg Young — 2012-05-21T09:29:01

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:

Re: The Economics of Reuse: DDD vs SOA

Remy Fannader — 2012-05-21T09:17:22

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<http://caminao.wordpress.com/about/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".

Re: The Economics of Reuse: DDD vs SOA

Greg Young — 2012-05-21T08:48:54

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:

Re: The Economics of Reuse: DDD vs SOA

Remy Fannader — 2012-05-21T08:31:25

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

Re: The Economics of Reuse: DDD vs SOA

Greg Young — 2012-05-21T06:28:17

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:

Re: The Economics of Reuse: DDD vs SOA

Remy Fannader — 2012-05-21T06:02:49

Geometry is not limited to 2D.
Remy.

Re: The Economics of Reuse: DDD vs SOA

Greg Young — 2012-05-21T05:44:40

" 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< at >gmail.com> wrote: