<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design">
    <title>gmane.comp.programming.domain-driven-design</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22370"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22369"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22368"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22367"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22366"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22365"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22364"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22363"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22362"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22361"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22360"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22359"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22358"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22357"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22356"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22355"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22354"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22353"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22352"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22351"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22370">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22370</link>
    <description>&lt;pre&gt;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:


&lt;/pre&gt;</description>
    <dc:creator>Nuno Lopes</dc:creator>
    <dc:date>2012-05-23T17:16:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22369">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22369</link>
    <description>&lt;pre&gt;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;&lt;/pre&gt;</description>
    <dc:creator>Nuno Lopes</dc:creator>
    <dc:date>2012-05-23T11:23:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22368">
    <title>Re: Questions : Relation between SOA, Domain Service, Repositories and Entities</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22368</link>
    <description>&lt;pre&gt;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 m&lt;/pre&gt;</description>
    <dc:creator>Moran Lefler</dc:creator>
    <dc:date>2012-05-23T06:29:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22367">
    <title>Re: Questions : Relation between SOA, Domain Service, Repositories and Entities</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22367</link>
    <description>&lt;pre&gt;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&lt;/pre&gt;</description>
    <dc:creator>Ryan Barrett</dc:creator>
    <dc:date>2012-05-22T21:08:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22366">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22366</link>
    <description>&lt;pre&gt;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:

     &amp;lt; at &amp;gt;Override
     &amp;lt; at &amp;gt;SuppressWarnings("unchecked")
     public Collection&amp;lt;CalendarEntry&amp;gt; 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 " +
  &lt;/pre&gt;</description>
    <dc:creator>vvernon_shiftmethod</dc:creator>
    <dc:date>2012-05-22T23:21:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22365">
    <title>Re: Questions : Relation between SOA, Domain Service, Repositories and Entities</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22365</link>
    <description>&lt;pre&gt;








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 &lt;/pre&gt;</description>
    <dc:creator>moranlf</dc:creator>
    <dc:date>2012-05-22T21:46:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22364">
    <title>Questions : Relation between SOA, Domain Service, Repositories and Entities</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22364</link>
    <description>&lt;pre&gt;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 &lt;/pre&gt;</description>
    <dc:creator>tiger_lu_hao</dc:creator>
    <dc:date>2012-05-22T01:51:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22363">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22363</link>
    <description>&lt;pre&gt;
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&amp;lt; at &amp;gt;yahoogroups.com, "sweetlandj" &amp;lt;sweetlandj&amp;lt; at &amp;gt;...&amp;gt; wrote:




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

&lt;/pre&gt;</description>
    <dc:creator>sebaszipp</dc:creator>
    <dc:date>2012-05-22T17:46:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22362">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22362</link>
    <description>&lt;pre&gt;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 th&lt;/pre&gt;</description>
    <dc:creator>sweetlandj</dc:creator>
    <dc:date>2012-05-22T13:47:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22361">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22361</link>
    <description>&lt;pre&gt;
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.&lt;/pre&gt;</description>
    <dc:creator>sebaszipp</dc:creator>
    <dc:date>2012-05-22T13:16:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22360">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22360</link>
    <description>&lt;pre&gt;Do you need to schedule more than 1000 years in the future?
On May 21, 2012 3:35 PM, "sebaszipp" &amp;lt;sebaszipp&amp;lt; at &amp;gt;yahoo.com&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Greg Young</dc:creator>
    <dc:date>2012-05-22T05:54:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22359">
    <title>Re: Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22359</link>
    <description>&lt;pre&gt;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&amp;lt; at &amp;gt;yahoogroups.com, "sebaszipp" &amp;lt;sebaszipp&amp;lt; at &amp;gt;...&amp;gt; wrote:



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

&lt;/pre&gt;</description>
    <dc:creator>sweetlandj</dc:creator>
    <dc:date>2012-05-21T14:32:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22358">
    <title>Calendar with recurring events</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22358</link>
    <description>&lt;pre&gt;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



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

&lt;/pre&gt;</description>
    <dc:creator>sebaszipp</dc:creator>
    <dc:date>2012-05-21T13:35:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22357">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22357</link>
    <description>&lt;pre&gt;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.
&lt;/pre&gt;</description>
    <dc:creator>Remy Fannader</dc:creator>
    <dc:date>2012-05-21T09:34:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22356">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22356</link>
    <description>&lt;pre&gt;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:



&lt;/pre&gt;</description>
    <dc:creator>Greg Young</dc:creator>
    <dc:date>2012-05-21T09:29:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22355">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22355</link>
    <description>&lt;pre&gt;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&amp;lt;http://caminao.wordpress.com/about/reflections-for-the-perplexed/&amp;gt;
".
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".
&lt;/pre&gt;</description>
    <dc:creator>Remy Fannader</dc:creator>
    <dc:date>2012-05-21T09:17:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22354">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22354</link>
    <description>&lt;pre&gt;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:



&lt;/pre&gt;</description>
    <dc:creator>Greg Young</dc:creator>
    <dc:date>2012-05-21T08:48:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22353">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22353</link>
    <description>&lt;pre&gt;If there is orthogonality (like for parallel execution states in
StateCharts), x and y are uncorrelated state variables.
&lt;/pre&gt;</description>
    <dc:creator>Remy Fannader</dc:creator>
    <dc:date>2012-05-21T08:31:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22352">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22352</link>
    <description>&lt;pre&gt;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:



&lt;/pre&gt;</description>
    <dc:creator>Greg Young</dc:creator>
    <dc:date>2012-05-21T06:28:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22351">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22351</link>
    <description>&lt;pre&gt;Geometry is not limited to 2D.
Remy.
&lt;/pre&gt;</description>
    <dc:creator>Remy Fannader</dc:creator>
    <dc:date>2012-05-21T06:02:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22350">
    <title>Re: The Economics of Reuse: DDD vs SOA</title>
    <link>http://permalink.gmane.org/gmane.comp.programming.domain-driven-design/22350</link>
    <description>&lt;pre&gt;" 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 &amp;lt;caminao&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>Greg Young</dc:creator>
    <dc:date>2012-05-21T05:44:40</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.programming.domain-driven-design">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.programming.domain-driven-design</link>
  </textinput>
</rdf:RDF>

