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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
