Let me first recap one of the things that quickly gets blown out of the water in regards to relational models in a COP environment...
Since each mixin has its own state, any solution involving SQL would end up with the following three choices; 1. Putting the entire state of the Composite into a single column (the implementation that exists do that) 2. Putting each Property and Association of the Composite into its own column in a single table. 3. Putting each Mixin in its own table. I don't think I need to explain 1. For 2; This is plain stupid, since all properties of all mixins are represented in that single table, it would largely be empty fields for most instances. So why not put each composite type in its own table? Well, for a given composite instance, it can have an arbitrary number of types (roles), so Apples, Bananas and Oranges are all both Fruit and maybe Sellable, but all Sellables are not Fruits. Will they end up in a Fruit table or a Sellable table? Expand that to 20 roles or more, and you might see a pattern --> How do you find things again? For 3; This has been discussed as viable option. The performance will suck, either from too many individual reads (on-demand as mixins are accessed) or massively large JOINs to bind 20 tables together. Also write performance will be poor. BUT, some applications are not that sensitive and perhaps someone with strong interest in the matter (hint! nudge!) could set out an make such an implementation. The effort required is probably "within reason", but outside the volunteer focus at the moment. Now, there was an effort previously to do an ORM-equivalent, i.e. some mapping mechanism to allow existing schemas to be mapped onto composite structures (with a bunch of constraints). It went under the name "QRM" (Qi4j-Relational-Mapping). This was made during a period when my previous company sponsored Qi4j development, and we had full time people on it and this was an area we thought needed solving. The QRM codebase was purged just a couple of weeks ago, if you want to take a look it is a matter of checking out Qi4j earlier in the year, for instance May 2012 or so. As for CAP; I would like to argue that the CAP theorem is wrongly quoted when most people mention it, like you did. The "P" is poorly understood. I won't go into the details on what happens with a Partitioned system (too big topic), but the conclusion is always that CA only possible with a single server. I would like to argue, that this is also a flawed view, since with a single server, if you loose connectivity (which is what partitioning in reality is) you also loose Availability. So, instead, I would like to reformulate the CAP theorem as; "When Partitioning occurs, do you want Availability or Consistency". It even works for "single server"-case where the answer is "Consistency". So a true CA system can only happen with a network-free application and use. That might also make you think, again depending on all your variables involved, such as throughput, latency, deployment methods, and much much more. But since you seem committed to CQRS/ES, I would assume that scale is important, as this is the primary driver to seek it out in the first place. Also, "accounting" or even "banking" is not dependent on consistency, as defined by CAP and NoSQL advocates. The only requirement that you really have is Eventual Consistency, with a time window that is defined by business requirements and more often than not, many magnitudes larger than what we software dudes think... Start with "All Data is Stale", and then work with people in the business asking "How old can this ... be?". I have seen examples where we thought "<10ms" and business said "<30minutes", or ~5 magnitudes error in guessing. Or how about this; Banks transfer funds between accounts in different banks. The "user transaction" could take place over a few days, but is normally eventually consistent. In fact, quite often this consistency fails altogether (money never arrives, nor sent back), and even then it is not end of the world. The "user" contact the bank and wants it corrected. Greg said something very important; Failing consistency is not a massive problem. As long as it can be detected and corrected after the fact. Adding, that we often spend too much energy solving problems that doesn't exist. I would also like to recommend you http://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577, of course because I helped Vaughn out a little bit on one chapter... And in case you haven't seen Greg's book; http://www.amazon.com/Event-Centric-Simplicity-Addison-Wesley-Signature/dp/0321768221 Hope that helps. Niclas On Mon, Oct 1, 2012 at 5:41 PM, Jiri Jetmar <[email protected]> wrote: > 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 -- 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
