You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Chris Geer <ch...@cxtsoftware.com> on 2012/07/24 18:26:06 UTC
Re: [Proposal] Model Isolation
On Thu, Jun 28, 2012 at 6:46 AM, Ate Douma <at...@douma.nu> wrote:
> On 06/28/2012 03:13 PM, Franklin, Matthew B. wrote:
>
>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Thursday, June 28, 2012 8:23 AM
>>> To: dev@rave.apache.org
>>> Subject: Re: [Proposal] Model Isolation
>>>
>>> On 06/28/2012 10:35 AM, Scott Wilson wrote:
>>>
>>>> On 28 Jun 2012, at 03:41, Chris Geer wrote:
>>>>
>>>> On Wed, Jun 27, 2012 at 6:50 PM, Franklin, Matthew B.
>>>>> <mf...@mitre.org>wrote:
>>>>>
>>>>> Chris asked the question in the past if we wanted to move all models
>>>>>> to
>>>>>> using IDs to reference related objects. I think this approach makes
>>>>>> sense
>>>>>> in certain cases and tight coupling makes sense in others. I have put
>>>>>> together a proposal for a balanced approach in the wiki [1].
>>>>>>
>>>>>> Given that each of these changes should be isolated enough, I think we
>>>>>>
>>>>> can
>>>
>>>> safely do this in trunk one class at a time.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>> I think we could even get away with combining Page and Widget groups.
>>>>>
>>>> Those
>>>
>>>> are pretty tightly linked and probably won't be separated.
>>>>>
>>>>> I think I can agree with that, for now.
>>> Although the sizing and scaling of the Page group might be very/extremely
>>> different from the Widget group. So separating these two might still be
>>> needed
>>> or at least considered.
>>>
>>
>> I think they need to be separated for the simple case that you want to
>> define your widgets in a separate store from your pages. I can see wanting
>> to keep Widgets in SQL while pages in a document store. Also, if you want
>> to connect to a separate widget store like edukapp, the widget model needs
>> to be separated.
>>
>> I don't see how nor do I expect Rave to externalize its widget storage,
> even if using an external edukapp like *shop* to retrieve new (or updated)
> widget definitions.
>
> But as I already said I can see the need to separate the storage of the
> widget model from the page model. So I'm also +1 to already cater for that
> need now.
>
>
>
>>> I made a small update to the group definitions: I moved the PageTemplate*
>>> types
>>> to a separate Page Prototyping group. AFAIK these have nothing so much to
>>> do
>>> with Page Rendering but are only used as 'prototype' when creating new
>>> Page*
>>> instances. Or maybe I misunderstood why the PageTemplate* types were
>>> grouped
>>> under Page Rendering?
>>>
>>
>> Prototyping is better. I only called it Rendering because I included the
>> layout, which is more of a runtime rendering pointer.
>>
>>
>>> Anyway, I'm working on an alternate dynamic and hierarchical
>>> PageDefinition/PageFragment model for the content-services sandbox which
>>> I
>>> intend as replacement for all the Page* groups. IMO the current model
>>> isn't
>>> going to scale or be maintainable so *some* changes will be needed for
>>> sure.
>>>
>>>
>> It should be a good start to isolate this then, right?
>>
> Well, yes. Or maybe. Depends on your POV and angle you're looking at it :)
>
> Note that the alternate PageDefinition model will need some time to flesh
> out and we're using the sandbox for that as a custom Rave extension project
> setup.
> So we do need to sync (API wise) with changes in trunk to pick them up. Or
> we may delay that depending on the amount of flux.
>
>
>
> > How close do you think you are to proposing that model?
> I'm currently prototyping with a bare minimal POJO model (runtime only)
> and we also will need a HMVC controller mapping first before we can start
> executing it.
> Next week Marijan and myself will work most or even full week on this.
> Marijan will continue on this the week thereafter and then take a 3 week
> holiday.
> And I will already take a 3 week holiday after next week.
>
> Starting August I will pick up where Marijan left, and Marijan will join
> the effort again in the 2nd week of August. And we intend to complete the
> majority of the work before/at the end of August.
>
> BTW: Ard will continue with and hopes to release next week a new/update
> Jackrabbit OCM module, if all goes well. Thereafter he'll start working on
> a JCR persistence module for Rave using this.
>
>
> I was hoping we could started on this next week at the latest...
>>
> Sure, why not.
>
> For trunk the effort in the sandbox is not yet relevant, nor should it
> hamper it. And most/all of the Model isolation makes sense anyway,
> regardless.
> I only expect/hope to replace all three Page* groups with this effort in
> the sandbox. So spending an enormous amour of time on (or better: within)
> these Model groups might be a bit wasteful.
I went ahead and created an initial JIRA item [1] and branch [2] to start
to work on this. After a few minutes of looking at this though I've come up
with a few questions I wanted to bring up for discussion.
1) IDs: Do we want to stick with longs for the IDs or move to a more
generic String? If we went with String it would allow implementors a lot of
variety in what they used under the covers for the ID (could still be a
number).
2) Services/Repositories: It seems to make sense that if we are grouping
things into dependent groups that there shouldn't
be separate services/repositories for all the items inside a group. I
updated the wiki page [3] to reflect my opinion on how we should
restructure the services/repositories.
Chris
>
>
>
>>
>>> One thing to consider though is how does a tightly coupled data model
>>>>>
>>>> work
>>>
>>>> for the various APIs? I've only done a little research but it looks like
>>>>> the REST API returns/accepts a pretty shallow data model. Would that
>>>>>
>>>> cause
>>>
>>>> problems with a richer backend data model?
>>>>>
>>>>
>>>> I think it may make sense to decouple the REST API data model from the
>>>>
>>> underlying model with some DTO classes representing just the data we want
>>> to expose.
>>>
>>>>
>>>> Yes, agreed on that.
>>>
>>> Related to this, I've spend last week some time looking into the project
>>> Qi4j
>>> project [1] and the underlying DDD [2], DCI [3] and CQRS [4] theory and
>>> practices.
>>>
>>> Although I think they (Qi4j) are on the right track and this potentially
>>> might
>>> be good for us (Rave) to look into, I also think its a bit too much and
>>> to far
>>> reaching right now to pick this up.
>>> Nonetheless the links below are recommended to read into if your
>>> interested.
>>>
>>> [1] http://www.qi4j.org/**introduction-background.html<http://www.qi4j.org/introduction-background.html>
>>> [2] http://en.wikipedia.org/wiki/**Domain-driven_design<http://en.wikipedia.org/wiki/Domain-driven_design>
>>> [3] http://www.artima.com/**articles/dci_vision.html<http://www.artima.com/articles/dci_vision.html>
>>> http://en.wikipedia.org/wiki/**Data,_context_and_interaction<http://en.wikipedia.org/wiki/Data,_context_and_interaction>
>>> [4] http://martinfowler.com/bliki/**CQRS.html<http://martinfowler.com/bliki/CQRS.html>
>>>
>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>> [1] :
>>>>>>
>>>>>> http://wiki.apache.org/rave/**ArchitectureTopics/**
>>> Persistence/ModelIsolation<http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation>
>>>
>>>>
>>>>>> -Matt
>>>>>>
>>>>>>
>>>>
>>>
>>
[1] https://issues.apache.org/jira/browse/RAVE-729
[2] http://svn.apache.org/repos/asf/rave/branches/model-split
<http://svn.apache.org/repos/asf/rave/branches/model-split>
[3]
http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation
Re: [Proposal] Model Isolation
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Tue, Jul 24, 2012 at 9:43 AM, Franklin, Matthew B.
<mf...@mitre.org>wrote:
> On 7/24/12 12:26 PM, "Chris Geer" <ch...@cxtsoftware.com> wrote:
>
> >On Thu, Jun 28, 2012 at 6:46 AM, Ate Douma <at...@douma.nu> wrote:
> >
> >> On 06/28/2012 03:13 PM, Franklin, Matthew B. wrote:
> >>
> >>> -----Original Message-----
> >>>> From: Ate Douma [mailto:ate@douma.nu]
> >>>> Sent: Thursday, June 28, 2012 8:23 AM
> >>>> To: dev@rave.apache.org
> >>>> Subject: Re: [Proposal] Model Isolation
> >>>>
> >>>> On 06/28/2012 10:35 AM, Scott Wilson wrote:
> >>>>
> >>>>> On 28 Jun 2012, at 03:41, Chris Geer wrote:
> >>>>>
> >>>>> On Wed, Jun 27, 2012 at 6:50 PM, Franklin, Matthew B.
> >>>>>> <mf...@mitre.org>wrote:
> >>>>>>
> >>>>>> Chris asked the question in the past if we wanted to move all
> >>>>>>models
> >>>>>>> to
> >>>>>>> using IDs to reference related objects. I think this approach
> >>>>>>>makes
> >>>>>>> sense
> >>>>>>> in certain cases and tight coupling makes sense in others. I have
> >>>>>>>put
> >>>>>>> together a proposal for a balanced approach in the wiki [1].
> >>>>>>>
> >>>>>>> Given that each of these changes should be isolated enough, I
> >>>>>>>think we
> >>>>>>>
> >>>>>> can
> >>>>
> >>>>> safely do this in trunk one class at a time.
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>>
> >>>>>> I think we could even get away with combining Page and Widget
> >>>>>>groups.
> >>>>>>
> >>>>> Those
> >>>>
> >>>>> are pretty tightly linked and probably won't be separated.
> >>>>>>
> >>>>>> I think I can agree with that, for now.
> >>>> Although the sizing and scaling of the Page group might be
> >>>>very/extremely
> >>>> different from the Widget group. So separating these two might still
> >>>>be
> >>>> needed
> >>>> or at least considered.
> >>>>
> >>>
> >>> I think they need to be separated for the simple case that you want to
> >>> define your widgets in a separate store from your pages. I can see
> >>>wanting
> >>> to keep Widgets in SQL while pages in a document store. Also, if you
> >>>want
> >>> to connect to a separate widget store like edukapp, the widget model
> >>>needs
> >>> to be separated.
> >>>
> >>> I don't see how nor do I expect Rave to externalize its widget
> >>>storage,
> >> even if using an external edukapp like *shop* to retrieve new (or
> >>updated)
> >> widget definitions.
> >>
> >> But as I already said I can see the need to separate the storage of the
> >> widget model from the page model. So I'm also +1 to already cater for
> >>that
> >> need now.
> >>
> >>
> >>
> >>>> I made a small update to the group definitions: I moved the
> >>>>PageTemplate*
> >>>> types
> >>>> to a separate Page Prototyping group. AFAIK these have nothing so
> >>>>much to
> >>>> do
> >>>> with Page Rendering but are only used as 'prototype' when creating new
> >>>> Page*
> >>>> instances. Or maybe I misunderstood why the PageTemplate* types were
> >>>> grouped
> >>>> under Page Rendering?
> >>>>
> >>>
> >>> Prototyping is better. I only called it Rendering because I included
> >>>the
> >>> layout, which is more of a runtime rendering pointer.
> >>>
> >>>
> >>>> Anyway, I'm working on an alternate dynamic and hierarchical
> >>>> PageDefinition/PageFragment model for the content-services sandbox
> >>>>which
> >>>> I
> >>>> intend as replacement for all the Page* groups. IMO the current model
> >>>> isn't
> >>>> going to scale or be maintainable so *some* changes will be needed for
> >>>> sure.
> >>>>
> >>>>
> >>> It should be a good start to isolate this then, right?
> >>>
> >> Well, yes. Or maybe. Depends on your POV and angle you're looking at it
> >>:)
> >>
> >> Note that the alternate PageDefinition model will need some time to
> >>flesh
> >> out and we're using the sandbox for that as a custom Rave extension
> >>project
> >> setup.
> >> So we do need to sync (API wise) with changes in trunk to pick them up.
> >>Or
> >> we may delay that depending on the amount of flux.
> >>
> >>
> >>
> >> > How close do you think you are to proposing that model?
> >> I'm currently prototyping with a bare minimal POJO model (runtime only)
> >> and we also will need a HMVC controller mapping first before we can
> >>start
> >> executing it.
> >> Next week Marijan and myself will work most or even full week on this.
> >> Marijan will continue on this the week thereafter and then take a 3 week
> >> holiday.
> >> And I will already take a 3 week holiday after next week.
> >>
> >> Starting August I will pick up where Marijan left, and Marijan will join
> >> the effort again in the 2nd week of August. And we intend to complete
> >>the
> >> majority of the work before/at the end of August.
> >>
> >> BTW: Ard will continue with and hopes to release next week a new/update
> >> Jackrabbit OCM module, if all goes well. Thereafter he'll start working
> >>on
> >> a JCR persistence module for Rave using this.
> >>
> >>
> >> I was hoping we could started on this next week at the latest...
> >>>
> >> Sure, why not.
> >>
> >> For trunk the effort in the sandbox is not yet relevant, nor should it
> >> hamper it. And most/all of the Model isolation makes sense anyway,
> >> regardless.
> >> I only expect/hope to replace all three Page* groups with this effort in
> >> the sandbox. So spending an enormous amour of time on (or better:
> >>within)
> >> these Model groups might be a bit wasteful.
> >
> >
> >I went ahead and created an initial JIRA item [1] and branch [2] to start
> >to work on this. After a few minutes of looking at this though I've come
> >up
> >with a few questions I wanted to bring up for discussion.
>
> Cool
>
> >
> >1) IDs: Do we want to stick with longs for the IDs or move to a more
> >generic String? If we went with String it would allow implementors a lot
> >of
> >variety in what they used under the covers for the ID (could still be a
> >number).
>
> My vote would be with a generic string
>
> >2) Services/Repositories: It seems to make sense that if we are grouping
> >things into dependent groups that there shouldn't
> >be separate services/repositories for all the items inside a group. I
> >updated the wiki page [3] to reflect my opinion on how we should
> >restructure the services/repositories.
>
> I think there is definitely value in having the discussion; but, I think
> we can start the work of isolation without solving it. In other words,
> how to organize the code layers is important, but something that is
> different than changing the model. My $0.02
>
Matt, the reason I bring it up is I'm not a huge fan of circular
relationships in an object model and was hoping to get rid of them. For
example, Widget references a list of WidgetComments however I don't think
each of those WidgetComment objects should have a reference back to the
Widget. If you do, you could actually build an object model where a Widget
has a Comment in it's list that has a reference to another Widget (granted,
that would mean there was a error somewhere else). This doesn't mean a
persistence implementation couldn't have those reverse relationships (i.e
JPA) but it wouldn't be in the public model. What do you think?
>
>
> >
> >Chris
> >
> >>
> >>
> >>
> >>>
> >>>> One thing to consider though is how does a tightly coupled data model
> >>>>>>
> >>>>> work
> >>>>
> >>>>> for the various APIs? I've only done a little research but it looks
> >>>>>like
> >>>>>> the REST API returns/accepts a pretty shallow data model. Would that
> >>>>>>
> >>>>> cause
> >>>>
> >>>>> problems with a richer backend data model?
> >>>>>>
> >>>>>
> >>>>> I think it may make sense to decouple the REST API data model from
> >>>>>the
> >>>>>
> >>>> underlying model with some DTO classes representing just the data we
> >>>>want
> >>>> to expose.
> >>>>
> >>>>>
> >>>>> Yes, agreed on that.
> >>>>
> >>>> Related to this, I've spend last week some time looking into the
> >>>>project
> >>>> Qi4j
> >>>> project [1] and the underlying DDD [2], DCI [3] and CQRS [4] theory
> >>>>and
> >>>> practices.
> >>>>
> >>>> Although I think they (Qi4j) are on the right track and this
> >>>>potentially
> >>>> might
> >>>> be good for us (Rave) to look into, I also think its a bit too much
> >>>>and
> >>>> to far
> >>>> reaching right now to pick this up.
> >>>> Nonetheless the links below are recommended to read into if your
> >>>> interested.
> >>>>
> >>>> [1]
> >>>>http://www.qi4j.org/**introduction-background.html<
> http://www.qi4j.org/
> >>>>introduction-background.html>
> >>>> [2]
> >>>>http://en.wikipedia.org/wiki/**Domain-driven_design<
> http://en.wikipedia
> >>>>.org/wiki/Domain-driven_design>
> >>>> [3]
> >>>>http://www.artima.com/**articles/dci_vision.html<
> http://www.artima.com/
> >>>>articles/dci_vision.html>
> >>>>
> >>>>http://en.wikipedia.org/wiki/**Data,_context_and_interaction<http://en
> .
> >>>>wikipedia.org/wiki/Data,_context_and_interaction>
> >>>> [4]
> >>>>http://martinfowler.com/bliki/**CQRS.html<
> http://martinfowler.com/bliki
> >>>>/CQRS.html>
> >>>>
> >>>>
> >>>>>> Chris
> >>>>>>
> >>>>>>
> >>>>>>> [1] :
> >>>>>>>
> >>>>>>> http://wiki.apache.org/rave/**ArchitectureTopics/**
> >>>>
> >>>>Persistence/ModelIsolation<
> http://wiki.apache.org/rave/ArchitectureTopi
> >>>>cs/Persistence/ModelIsolation>
> >>>>
> >>>>>
> >>>>>>> -Matt
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >[1] https://issues.apache.org/jira/browse/RAVE-729
> >[2] http://svn.apache.org/repos/asf/rave/branches/model-split
> ><http://svn.apache.org/repos/asf/rave/branches/model-split>
> >[3]
> >http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation
>
>
Re: [Proposal] Model Isolation
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 7/24/12 12:26 PM, "Chris Geer" <ch...@cxtsoftware.com> wrote:
>On Thu, Jun 28, 2012 at 6:46 AM, Ate Douma <at...@douma.nu> wrote:
>
>> On 06/28/2012 03:13 PM, Franklin, Matthew B. wrote:
>>
>>> -----Original Message-----
>>>> From: Ate Douma [mailto:ate@douma.nu]
>>>> Sent: Thursday, June 28, 2012 8:23 AM
>>>> To: dev@rave.apache.org
>>>> Subject: Re: [Proposal] Model Isolation
>>>>
>>>> On 06/28/2012 10:35 AM, Scott Wilson wrote:
>>>>
>>>>> On 28 Jun 2012, at 03:41, Chris Geer wrote:
>>>>>
>>>>> On Wed, Jun 27, 2012 at 6:50 PM, Franklin, Matthew B.
>>>>>> <mf...@mitre.org>wrote:
>>>>>>
>>>>>> Chris asked the question in the past if we wanted to move all
>>>>>>models
>>>>>>> to
>>>>>>> using IDs to reference related objects. I think this approach
>>>>>>>makes
>>>>>>> sense
>>>>>>> in certain cases and tight coupling makes sense in others. I have
>>>>>>>put
>>>>>>> together a proposal for a balanced approach in the wiki [1].
>>>>>>>
>>>>>>> Given that each of these changes should be isolated enough, I
>>>>>>>think we
>>>>>>>
>>>>>> can
>>>>
>>>>> safely do this in trunk one class at a time.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>>
>>>>>> I think we could even get away with combining Page and Widget
>>>>>>groups.
>>>>>>
>>>>> Those
>>>>
>>>>> are pretty tightly linked and probably won't be separated.
>>>>>>
>>>>>> I think I can agree with that, for now.
>>>> Although the sizing and scaling of the Page group might be
>>>>very/extremely
>>>> different from the Widget group. So separating these two might still
>>>>be
>>>> needed
>>>> or at least considered.
>>>>
>>>
>>> I think they need to be separated for the simple case that you want to
>>> define your widgets in a separate store from your pages. I can see
>>>wanting
>>> to keep Widgets in SQL while pages in a document store. Also, if you
>>>want
>>> to connect to a separate widget store like edukapp, the widget model
>>>needs
>>> to be separated.
>>>
>>> I don't see how nor do I expect Rave to externalize its widget
>>>storage,
>> even if using an external edukapp like *shop* to retrieve new (or
>>updated)
>> widget definitions.
>>
>> But as I already said I can see the need to separate the storage of the
>> widget model from the page model. So I'm also +1 to already cater for
>>that
>> need now.
>>
>>
>>
>>>> I made a small update to the group definitions: I moved the
>>>>PageTemplate*
>>>> types
>>>> to a separate Page Prototyping group. AFAIK these have nothing so
>>>>much to
>>>> do
>>>> with Page Rendering but are only used as 'prototype' when creating new
>>>> Page*
>>>> instances. Or maybe I misunderstood why the PageTemplate* types were
>>>> grouped
>>>> under Page Rendering?
>>>>
>>>
>>> Prototyping is better. I only called it Rendering because I included
>>>the
>>> layout, which is more of a runtime rendering pointer.
>>>
>>>
>>>> Anyway, I'm working on an alternate dynamic and hierarchical
>>>> PageDefinition/PageFragment model for the content-services sandbox
>>>>which
>>>> I
>>>> intend as replacement for all the Page* groups. IMO the current model
>>>> isn't
>>>> going to scale or be maintainable so *some* changes will be needed for
>>>> sure.
>>>>
>>>>
>>> It should be a good start to isolate this then, right?
>>>
>> Well, yes. Or maybe. Depends on your POV and angle you're looking at it
>>:)
>>
>> Note that the alternate PageDefinition model will need some time to
>>flesh
>> out and we're using the sandbox for that as a custom Rave extension
>>project
>> setup.
>> So we do need to sync (API wise) with changes in trunk to pick them up.
>>Or
>> we may delay that depending on the amount of flux.
>>
>>
>>
>> > How close do you think you are to proposing that model?
>> I'm currently prototyping with a bare minimal POJO model (runtime only)
>> and we also will need a HMVC controller mapping first before we can
>>start
>> executing it.
>> Next week Marijan and myself will work most or even full week on this.
>> Marijan will continue on this the week thereafter and then take a 3 week
>> holiday.
>> And I will already take a 3 week holiday after next week.
>>
>> Starting August I will pick up where Marijan left, and Marijan will join
>> the effort again in the 2nd week of August. And we intend to complete
>>the
>> majority of the work before/at the end of August.
>>
>> BTW: Ard will continue with and hopes to release next week a new/update
>> Jackrabbit OCM module, if all goes well. Thereafter he'll start working
>>on
>> a JCR persistence module for Rave using this.
>>
>>
>> I was hoping we could started on this next week at the latest...
>>>
>> Sure, why not.
>>
>> For trunk the effort in the sandbox is not yet relevant, nor should it
>> hamper it. And most/all of the Model isolation makes sense anyway,
>> regardless.
>> I only expect/hope to replace all three Page* groups with this effort in
>> the sandbox. So spending an enormous amour of time on (or better:
>>within)
>> these Model groups might be a bit wasteful.
>
>
>I went ahead and created an initial JIRA item [1] and branch [2] to start
>to work on this. After a few minutes of looking at this though I've come
>up
>with a few questions I wanted to bring up for discussion.
Cool
>
>1) IDs: Do we want to stick with longs for the IDs or move to a more
>generic String? If we went with String it would allow implementors a lot
>of
>variety in what they used under the covers for the ID (could still be a
>number).
My vote would be with a generic string
>2) Services/Repositories: It seems to make sense that if we are grouping
>things into dependent groups that there shouldn't
>be separate services/repositories for all the items inside a group. I
>updated the wiki page [3] to reflect my opinion on how we should
>restructure the services/repositories.
I think there is definitely value in having the discussion; but, I think
we can start the work of isolation without solving it. In other words,
how to organize the code layers is important, but something that is
different than changing the model. My $0.02
>
>Chris
>
>>
>>
>>
>>>
>>>> One thing to consider though is how does a tightly coupled data model
>>>>>>
>>>>> work
>>>>
>>>>> for the various APIs? I've only done a little research but it looks
>>>>>like
>>>>>> the REST API returns/accepts a pretty shallow data model. Would that
>>>>>>
>>>>> cause
>>>>
>>>>> problems with a richer backend data model?
>>>>>>
>>>>>
>>>>> I think it may make sense to decouple the REST API data model from
>>>>>the
>>>>>
>>>> underlying model with some DTO classes representing just the data we
>>>>want
>>>> to expose.
>>>>
>>>>>
>>>>> Yes, agreed on that.
>>>>
>>>> Related to this, I've spend last week some time looking into the
>>>>project
>>>> Qi4j
>>>> project [1] and the underlying DDD [2], DCI [3] and CQRS [4] theory
>>>>and
>>>> practices.
>>>>
>>>> Although I think they (Qi4j) are on the right track and this
>>>>potentially
>>>> might
>>>> be good for us (Rave) to look into, I also think its a bit too much
>>>>and
>>>> to far
>>>> reaching right now to pick this up.
>>>> Nonetheless the links below are recommended to read into if your
>>>> interested.
>>>>
>>>> [1]
>>>>http://www.qi4j.org/**introduction-background.html<http://www.qi4j.org/
>>>>introduction-background.html>
>>>> [2]
>>>>http://en.wikipedia.org/wiki/**Domain-driven_design<http://en.wikipedia
>>>>.org/wiki/Domain-driven_design>
>>>> [3]
>>>>http://www.artima.com/**articles/dci_vision.html<http://www.artima.com/
>>>>articles/dci_vision.html>
>>>>
>>>>http://en.wikipedia.org/wiki/**Data,_context_and_interaction<http://en.
>>>>wikipedia.org/wiki/Data,_context_and_interaction>
>>>> [4]
>>>>http://martinfowler.com/bliki/**CQRS.html<http://martinfowler.com/bliki
>>>>/CQRS.html>
>>>>
>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>> [1] :
>>>>>>>
>>>>>>> http://wiki.apache.org/rave/**ArchitectureTopics/**
>>>>
>>>>Persistence/ModelIsolation<http://wiki.apache.org/rave/ArchitectureTopi
>>>>cs/Persistence/ModelIsolation>
>>>>
>>>>>
>>>>>>> -Matt
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>[1] https://issues.apache.org/jira/browse/RAVE-729
>[2] http://svn.apache.org/repos/asf/rave/branches/model-split
><http://svn.apache.org/repos/asf/rave/branches/model-split>
>[3]
>http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation