Ok, this is a classic question, and the answer is spread out on the site...
The "principle" that we oppose to is that "store/retrieve" operations for the domain model should not be hampered by 3rd party requirements, especially since those requirements vary a great deal. Google CQRS and Event Sourcing (both promoted by Greg Young) to understand how large scale modeling with this in mind should take place. Ever heard, use the best tool for the job? Well, the job shouldn't be "storage+indexing+data mining+adhoc query+reporting+backup+batch processing", but each term individually. Compare it to WWW, if Oracle would have gotten the idea to create something like WWW, and model it with SQL in mind, imagine.... Once you accept this, your domain model becomes much more "supple" (as Eric Evans describes the phenomenon), you can make fairly aggressive changes within the model to meet new requirements and changing market conditions. The "traditional" approach of effectively static DB schema is an anti-pattern, which leads to all kinds of work-arounds to avoid change. I hope you will overcome your "demons" ;-) and abandon the shared RDBMS anti-pattern. Each application should own its data, sharing is an integration point, and all integration consumes enormous amount of effort (>80% where I work). And once your store/retrieves goes from 100s (or less) per second to 1000s per second (per host), your application modeling will change with it. If you are making web applications, then sessions will disappear, you might even go to a HATEOAS and DCI style, like Rickard did in Streamflow. Cheers Niclas On Sun, Sep 30, 2012 at 11:42 PM, jj <[email protected]> wrote: > Hello gents, > > First of all I want to thank you for providing Qi4j – there are really some > unique ideas behind this project. > I spent the last couple of days trying to figure out the key concepts, used > patterns & principles. > To separate the state and the role-dependent behavior is from my point of > view really interesting and it matches > with my experience I collected in the projects I was involved in. > > Ok, what I still not yet really is the idea how to persist the states – > means how to persist the entities. > Especially when considering the SQL Entity Storage. I tried the Postgresql > examples and realize that all the > entities in the example code are persist to a table called > “schema.qi4j-entities”. > > Our domain model includes about 100-120 key entities and it would be a > pleasure to model them in the Qi4j > semantics. But the “materialized” schema – in our case the SQL schema must > reflect the model as we have e.g. > reporting tools that expects to query an SQL database. I’m not sure if I > completely miss the point but I was > somehow not able to figure the basic principle from the source code (also > due lack of time.. ). Maybe you guys > are able to give me a brief intro about the basics (SQL) persistence > concepts.. > > Thank you in advance. > > jj > > > > > -- > View this message in context: > http://qi4j-dev.23929.n6.nabble.com/SQL-Entity-Storage-Basic-Principles-tp7077.html > Sent from the Qi4j-dev mailing list archive at Nabble.com. > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- Niclas Hedhman, Software Developer 河南南路555弄15号1901室。 http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
