Hello Stanislav, Niclas many thanks for the reply.
In do agree with the most of your statement Niclas and our architecture is CQRS + ES based and I think it makes sense to distinguish between a transactional write model and a read-only/query model. Our architecture reflects the ideas summarized in the two books from Eric Evans and James Coplien (the blue + red book). And because our technical run time platform is the JVM we are very interested to use Qi4j for the domain model and the behavioral implementation. Also because of the many other smart ideas like layering/structuring the Application using the Modules etc.. and DCI - of course. But as mentioned the only "issue" we have now with Qi4j is the concrete persistence implementation.. and I;m trying hardly to derive a concrete and pragmatic implementation concept based on your statements.. We have as a team about 30+ years of experience in relational databases and they are pretty mature and stable nowadays (we are using postgresql) and therefore it would be excellent to use this database as our entity storage. Also because we use some additional extensions like the Spatial Module (PostGIS) to do some search operations on spatially distributed items. The system does "accounting" means doing some bookings, transactions on accounts, position-keeping so that we really rely on a mature, well understood, transactional entity storage.. Sure we would like to build a architecture that scales well but referring the CAP-theorem we have to choose (at least for the accounting sub-domain) two characteristics and a typical accounting component has to be consistent all the time and of course available (CA) and we have to live with the fact that the system is not partition-tolerant. I have looked briefly on Neo4J which looks promising but this is a complete paradigm-change, at least for us. Therefore I want to avoid any "revolutions" in that critical area (accounting) and prefer an "evolution" what we are doing now with the CQRS + DCI approach. What do you think guys. If you have to design a system like I briefly described based on Qi4j which approach you would chosen ? Thank you. Cheers, Jiri 2012/10/1 Niclas Hedhman <[email protected]>: > 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 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
