Fwd: [qi4j-dev] Qi4j: what's the goal anyway?

[Niclas Hedhman <ni...@hedhman.org>]

Almost 4 years ago Rickard posted this very juicy mail to the qi4j-dev
mailing list. I think a lot of this content is still very valid, hence
posting it again as a "reminder"....

Enjoy!
Niclas

---------- Forwarded message ----------
From: Rickard Öberg <ri...@gmail.com>
Date: Fri, Jul 29, 2011 at 7:36 AM
Subject: [qi4j-dev] Qi4j: what's the goal anyway?
To: Qi4j Dev <qi...@lists.ops4j.org>


Hi,

I'd like to ask the question of what is the point with Qi4j, with the
software framework landscape being as it is. I'd very much like your
feedback on the questions and assertions below, to see if it makes sense.

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. 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. 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.

Then there's the competition. What is the competition? The way I see it you
have JavaEE and Spring on the one end, and then new-kids-on-the-block like
Rails on the other. JavaEE is "standard", and Spring is becoming a de-facto
standard. Everybody "knows it", and it shows up in job CVs and
descriptions. The Rails guys seems to be banking a lot on the "get up and
running quickly" train. What separates Qi4j from these frameworks is that,
IF we have app templates, not only would you be able to get up and running
fast, but AFTER the first version you would actually be able to grow
without too much pain. Support for refactoring, JMX and admin,
CircuitBreakers, and other evolution/admin features, gives us an edge,
along with the modeling possibilities that just aren't there in other
frameworks.

So what gives? My thoughts, and here's where I need your feedback, is that
Qi4j 2.0 should focus on simplicity and productivity, as well as feature
completeness. This means:
* Templates for common app structures, where developers "fill in the
blanks", e.g. "domain goes here, app services here, REST goes here".
Convention over configuration, but architecturally as well as on the code.
With the recent ClassScanner tool, this can even be "put these kinds of
classes in this package", and the ClassScanner can pick them up
automatically.
* IDE plugins. We have Envisage now, but it is getting outdated. I would
like to change it into something like a IDEA plugin where you can click
"Refresh" (like the Gradle plugin), and it would show you what your app
looks like. Now that assembly is getting to a point where you don't
necessarily have to instantiate the app that is created, this should be
relatively easy
* Support for traditional technologies, specifically on the DB side. We
need to support storing data in SQL databases easily, for the simple reason
that admins know how to manage and backup these critters. As simple as
that. They can also provide scaling features, if necessary.
* More support for NOSQL. Adding e.g. CouchDB and MongoDB should be
trivial. I don't know how much these are actually used, but adding them as
EntityStores should a simple exercise, so why not?
* Support for standard JSR's, such as 303 (Validation) and 330 (Injection),
should be reasonably easy to do, and lowers the learning curve on these
things. Validation and Injection is a big part of every day work, so this
is important.
* 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.
* Getting a full stack. The main missing point to get a "full stack", as it
is, is the REST part. I have this, and can port it to Qi4j, so that should
be doable. Once that is in place we have a good end-to-end stack for
building apps, I think.

So those are my thoughts on this. Is it doable? Or should I give up on
this? Is it possible to get any meaningful "marketshare" with Qi4j, if v2.0
has all of the above? What is important? What is not important? What do you
guys think?

regards, Rickard

-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java