Hi Rickard, Thank you for your detailed report and questions.
On 2011-07-29, at 06.36, Rickard Öberg wrote: > I'd like to ask the question of what is the point with Qi4j, with the > software framework landscape being as it is. Among other purposes, I think Qi4j has its place to _make_ frameworks! > When me and Niclas started this project a long time ago, there were a couple > of different things that I personally wanted to address. First of all it was > the composite notion, that a domain object should be able to use mixins, not > only for code but also state. Being able to use a roles-oriented approach > significantly helps when building real-world applications. I think the theory > behind e.g. DCI validates this quite a bit. I can confirm this with a profound YES!! I got caugh up in holidays but now I'm rounding off the release of the DCI sample which will also confirm this in a really convincing way to a wider audience, I think (_hope_ - really - to release this week :-) > Some of you know the backstory that in 2002 I tried using JBoss/EJB to build > my first enterprise app (SiteVision), and gave up after two weeks. It just > wasn't possible. And then I *had* to create the forerunner to Qi4j, just to > "get stuff done". I don't know how other developers can take the pain > involved with standard modeling tools and ORM's and all that nonsense, but > that was my experience anywa. > > Another goal was to try and make AOP simpler. The ideas behind AOP are good, > but AspectJ, as the main implementation, is just too complicated. The > approach we adopted in Qi4j, with concerns/sideeffects being registered on > the composites, made it much more explicit where these things go, and makes > it in the end easier to read the code. We now have the option of specifying > these in the assembly, as well as role types and mixins, so if you want you > can apply application-wide concerns quite easily. It all ends up in the model > anyway, which can be visualized. > > Then, I also wanted to support DDD better. DDD in itself is mainly a process, > which technically doesn't require a framework, but by adopting some of its > terminology, specifically Entity, Value, UnitOfWork, etc. we make it easier > for those who want to do that. > > And finally, I have always been frustrated with Worditectures, where > architectural layers and modules are only in a Word document, and not in > code. If these constraints are not enforced at runtime, it's too easy to > break these things, which is not so good. > > So that's pretty much it. And that's a lot! +1 > Good stuff. There's only one problem. It takes quite some developer to > understand one of these things, and a very decent developer to understand all > of it, and then a really good developer to actually be able to implement it > without making a mess. David Leangen said to me that "Qi4j is 10 years ahead > of its time". In part that was true, as some of the theoretical background, > such as DCI, is only now being explored. A bigger issue is that the level of > developer it takes, at any point in time, to architect a good Qi4j app is > just too high. And then you need to teach the developers on the team how to > do it. I've done it now with my devs, and I know Niclas has had great success > on his side (in spite of initial ruffling and sneering), so it is possible. > > Qi4j is also like an empty Word document. You can do anything, but if you > don't know where to start, it's a bit daunting. Now that I've done Streamflow > I can see a general pattern for how to do it, and making another app like it > would be much easier. In other words, one of the things we're lacking is a > decent template, or "scaffolding", for apps, where you can more or less just > "fill in the blanks". Most frameworks these days do this, and it would make > sense for us to have this as well. > * Documentation. I've said this before, and I suck at doing it, but it's > still important. Documenting the basics, as well as common patterns. I still > feel like we need some kind of wiki-style website for this to be really easy > to do. I think documentation and tutorials are primary. Without those, the programmer will still have difficulty understanding scaffolded code. So I think we should start with the "communication core" which is organized documentation (including examples of course) and tests that you can study. Please see my suggestions regarding this in separate thread. > So those are my thoughts on this. Is it doable? Or should I give up on this? NOOOO, please continue!!! It's a fantastic job you and Niclas have put into this "beautiful ship" (Paul?). It just hasn't sailed into the big harbours yet as it deserves to. cheers, Marc _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
