On 7/30/11 11:58 , Niclas Hedhman wrote:
There is probably only one developer who is capable of thinking in
pure roles, and I wonder if that is even possible when you are not an
expert in the domain itself. Most domain experts thinks in terms of
"things" and then a divergence of one of data manipulation,
math/algorithms, actions. The CQRS mantra of "Commands" and "Events"
seems to be easy-enough concepts to introduce to domain experts, but
modeling in "roles" is really really tough.
When it comes to roles, if you apply DCI I think it gets easier. The
Roles are the algorithms, and the Data is the "thing". Start by having
one Data mixin for all data, and then split it as reuse possibilities
occur, or where it is obvious that some fields relate to different
aspects of an Entity.
I chose to NOT introduce the developers around me to anything beyond
"things" with Property, Value, Service, Entity, and only Mixins. Then
allowed them to "discover" advanced features by "accident" looking at
code that I wrote. For instance, I created a metrics subsystem, that
measures the execution time of methods, and which mixins to measure
are added at assembly. When one guy saw that, he went "Wow!!!"...
Yeah, I think that's how it should be done.
It is an amazing marketing stunt that Spring has managed. Not only do
they claim that your code doesn't depend on Spring itself, but they
also claim that everyone understands it automatically. We have heaps
of libraries that uses all the Spring magic in the book, and without
it nothing can be made to work. And with all components being XyzAware
something, means that even a small utility library brings in the
entire Spring stack (bad packaging on our part though).
It's a nice scam, indeed. Well done, I would say.
It is very very impressive. Even to a hard core "no other language"
old fart like me.
Java EE tooling is also trying to get to that. And sometimes I think
"maybe they are right, maybe most apps are simple enough...", then I
realize "but then the main time spent is not on coding, but other
things like deployment".
Agreed. Coding itself, the typing part, is to me not all that important.
It's the conceptual model that is of more importance, because it is
going to determine how much your app can "grow" once requirements add on
to the initial idea.
Our "post get-go" case is really really strong, unlike Rails, which
either can do it, or you are back to "on your own" and need to
integrate into the Rails structures, which may or may not suit the
(non-Rails suited) application.
My worry is; IF we have a Rails like approach to the "get up and
running quickly", would that mean that many developers will get
"shocked out of their pants" when they leave the "protected
environment" and venture into "native" Qi4j??
Maybe. Impossible to tell up-front, I think.
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.
Simply Productive!
Nice one :-)
* Templates for common app structures, where developers "fill in the
blanks", e.g. "domain goes here, app services here, REST goes here".
Not sure what you mean by 'templates'. Before we start that, we would
need to categorize N application types, since a consumer webapp would
be radically different than a financial messaging system.
Agreed. For my own case, with a "consumer webapp" (albeit with a Swing
client), I can see a typical architectural layout with a number of
layers that I would setup in the same way in any such app
(REST,Application,Context,Domain,Infrastructure,Management,Configuration).
Then it's mostly "fill in the blanks". Other types of apps may require a
different layering. No harm in having several templates, as long as it
is clear what is what.
Apart from the layering, it would also be useful to have some standard
services registered, like PreferencesEntityStore for configuration, some
JMX stuff, etc. which should always be there.
Convention over configuration, but architecturally as well as on the code.
One thing that I would like to change is the @UseDefaults and
@Optional. The person that writes the code, for instance an
Configuration type, doesn't know whether the user wants to rely on
defaults or not. I have not analyzed the exact need, but I think
@UseDefaults should simply 'go away' and IF it is declared in
bootstrap, then default value will be used if nothing is specified.
In that case, it has to become easier to declare defaults I think. It's
a bit messy right now, as the defaults are not clearly related to the
composite that it should be applied to.
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.
I also think we should reconsider the "Layered Architecture". We know
that the "Onion Architecture" is often a valid case, and I think we
should support it much stronger. This would impact quite a bit and I
wonder if the architecture can (I would like it to) be pluggable.
Worthwhile serious investigation.
With the current Application/Layer/Module setup I think you can do both
traditional pancake, onion and hexagonal architectures, which should be
good enough. Is there anything in the current structure that you see do
not support e.g. onion architectures?
Yes. Envisage also suffers from a deadlock bug in Prefuse. Need a
large revamp of the whole approach. The IDEA plugin has also been
bit-rotting for quite a while. There was some good features in there,
such as inspecting if any missing mixin methods. And we had a huge
list of good stuff one could add. Just that I am not good at plugin
development.
With IDEA gone open source licensing (Apache License some more!!) on
the Community Edition, I think we have less incentive to support
Eclipse as a "must have".
+1
* 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.
I thought the SQL entity store is pretty straight forward. I have not
used it, and perhaps we need to improve it. But perhaps you are
talking about Mapping, which is a much more complex matter.
I'd like to have a simple blobstore, i.e. viewing the SQL database as a
plain key-value store.
* More support for NOSQL. Adding e.g. CouchDB and MongoDB should be trivial.
I think they are not trivial from testing point of view. ie. how hard
is it to auto-download and start each of these to run the tests
against them?
Similar problem to the SQL entity store, which one would like to have
tested against as many DBs as possible.
That is true. For the developer doing it, it would be simple. For
centralized automated testing it would be worse, for sure. But we
already have this with e.g. PostgreSQL support.
YES! I am not convinced that Wiki-style website will be any more
successful than SiteVision. It isn't the tool, but the editors. Sure,
we say "If I had this tool instead, then I would...", but I think that
is partly a matter of excusing oneself.
Instead, I think versioned docs at source code level is better. Not
when it comes to marketing and all of that, but to get all details of
all features on digital paper. And as a measure of enforcement,
prohibit check-ins to 'develop' on any code that doesn't have Javadoc
on all public methods for instance. All packages must have at least N
words in package-info.java, and so on...
Probably true.
It is a difficult topic. No one likes to do it, I have been forcing
myself many many times, but it is a chore I am not happy doing,
especially since the need is massive and after spending one whole day
writing docs, it isn't a noticeable difference.
I see what you mean.
* Getting a full stack.
Again, that would depend on "application type". For instance, you use
methods as "Commands" where as I use "Command Objects", which would
require a different "stack".
Agree, I was thinking of "webapps", as a start.
Since my project at work is now cancelled, I will try and re-implement
some of the grid features that I put in place there;
* Trails - Command/Event sequences which recorded method calls and
log statements in a 'trail' so one could troubleshoot a single
'invocation' (for instance a timer tick).
* Commands - Command Objects are dispatched to the node where the
Aggregate Root resides and execute there to reduce network traffic.
Full recoverability in case of JVM or hardware failures.
* Events - Many grid nodes subscribe to the same event at the same
location in the code. But most often one only wants one of the event
handlers to receive it, typically resulting in further processing.
We already have an Event-library, which probably could be expanded to
support the above. Adding a complementary Command-library for the
incoming side should be possible, based on the same pattern.
* Limited Service - Often one need to run a reduced number of
services, when all deployed uniformly on all machines. For instance,
number of DB connections are limited.
Agreed! This is important for clustered cases, where you only want one
machine to (for example) send emails and other outgoing tasks.
I think that 2.0 should be a Core Feature release, meaning the changes
to the type system, all the incompatible changes we need to make,
perhaps the support for "Onion Architecture" and similar.
Once that is out, we focus 2.1/2.5 on the "Stack", "Fast Track",
"Integration" and "Tools".
Makes sense.
And I think I need to get out of my current fulltime job. It really
sucks my energy dry. Even weekends are ruined, and I just want to lay
in sofa and do nothing. Perhaps it was a bad idea to give up
CodeDragons.
Anyone out there who wants to sponsor Qi4j development by hiring me
full time? ;-)
That would be awesome :-)
regards, Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
