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.
<[email protected]>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 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?
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.
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
[2] http://en.wikipedia.org/wiki/Domain-driven_design
[3] http://www.artima.com/articles/dci_vision.html
http://en.wikipedia.org/wiki/Data,_context_and_interaction
[4] http://martinfowler.com/bliki/CQRS.html
Chris
[1] :
http://wiki.apache.org/rave/ArchitectureTopics/Persistence/ModelIsolation
-Matt
