Hi everyone,
The Maven test of the fantastic Axon Auction sample on Windows
fails with the following output:
Hi!
Do you have the current version of the "axon-support" project?
I changed the Joda* classes not so long ago - There were some changes
in the Axon 1.0 release.
If I run the tests everything works fine.
Cheers,
Michael
Hi Michael,
The screen-shot of the failure in Eclipse: http://d.pr/MePj
I'm running the latest source-code of the Auction sample
from the trunk. I've only changed the version of the
Axon-Core from from RC to the release.
I get the same result on both Win7-32 and Win7-64.
Regards,
Esfand
Hi Esfand,
I think that's the point.
I've only changed the version of the
Axon-Core from from RC to the release.
I tested it only with the RC version. For the moment I'd suggest you
use the version in the repository. I'll switch to the new Axon release
version the next few days and fix the problem.
Cheers,
Michael
Hi Michael,
Thanks a lot for your response and the good news about upgrading
Auction sample to work with the Axon 1.0 release.
BTW, I get the same result using Axon 1.0-rc3 specified in the
Axon-support module's pom.xml file present on the trunk. But it
is a minor issue anyways.
As a matter of fact, Auction sample is one of a few relatively
size-able maven modular projects I've seen that works flawlessly
(with the exception the couple of minor trivial issues I've
mentioned).
No warnings. No missing repositories. No problems! I started
browsing
your sample to learn Axon, but It turned-out that I'm learning a lot
of good Java programming techniques from it too. The idea of having
a complementary code-generator for Axon, you mentioned in the other
thread, is an excellent idea too which makes approaching CQRS less
painful.
I have a couple of other questions regarding the design of the
Auction sample that I'll ask in separate threads, if you don't
mind, now that I discovered we have your attention to this forum.
Thanks again for your help.
Best wishes,
Esfand
Hi Esfand,
I have a couple of other questions regarding the design of the
Auction sample that I'll ask in separate threads, if you don't
mind, now that I discovered we have your attention to this forum.
Just ask.
I started creating the code generator because I found there was much
boilerplate code in the auction example and it was difficult to keep
things like properties aligned between Commands, Events, Messages and
Queries. I hope to get the generator working over the next few weeks.
After that I will continue working on the Axon Auction Example.
Cheers,
Michael
Hi Michael,
I found there was much boilerplate code
in the auction example ...
This is just typical for any applications that my need Axon,
or even CQRS in general. In my case, to warm-up with Axon,
I picked a small legacy application with 20+ SQL table for
renovation. It was really an eye opener to discover that a
big portion of the fields was there just for the convenience
of the client applications. But, even the cleaned-up set of
tables has hundreds of fields. Scary enough for me to give
up on the idea because of the amount of the boiler-plate
needed. To make the matter worse, because of my lack of
experience with Axon, I wasn't even sure I could get it right
the very first time. The idea of going back and changing
the classes again, (and possibly) again, was a nightmare.
Nothing in the above story is specific to me and my
application. I'm sure it's a general problem. Therefore
thank you on behalf of everybody for coming-up with the
idea of Axon-specific code-generator.
To give me some hint, about the kind of code I may need to
generate to be used as input to your code-generator, could
you please describe the domain-model of your code-generator
you currently have in mind? I know it may be too early, so
just high-level description would be good enough.
Regards,
Esfand
Hi,
To give me some hint, about the kind of code I may need to
generate to be used as input to your code-generator, could
you please describe the domain-model of your code-generator
you currently have in mind? I know it may be too early, so
just high-level description would be good enough.
Most of the data structures is still the same as in my first & old XML
based try:
http://code.google.com/p/axon-auction-example/source/browse/#svn%2Ftrunk%2Fauction-parent%2Fdsl
I previously used this XML structure to generate all classes you can
find in the "src-gen" folders:
http://code.google.com/p/axon-auction-example/source/browse/#svn%2Ftrunk%2Fauction-command-api%2Fsrc-gen
(Example)
The big difference is, that the application itself is based on the
Axon Framework. It's a Swing application that makes it very easy to
create and edit all kind of CQRS/DDD style objects (Aggregates,
Commands, Events...). I'm currently working toward a point where I can
generate the application itself (It's a kind of "bootstrapping") -
Curently I'm doing all things manually...
I think I can create some screenshots this evening that shows the
current state.
Cheers,
Michael
Hi Esfand,
the duplicated-property-problem is an inherent problem of using commands and events in your API (which is in turn very common in CQRS-based applications). In many applications, you’ll use DoSomethingCommand to generate a SomethingWasDoneEvent which contains very similar, if not the same, information.
However, in my own projects, we spent some time to model the domain so that the number of properties diminishes drastically. Using value objects helps a lot. For example, combine firstname, last name, initials, etc into a Name value object and street, house number, city, zipcode into an Address. You’d then only need to pass around a Name or Address object. These examples are pretty obvious, but if you look close enough, many properties you have are “combinable”. If you annotate these classes with JPA annotations, you can also store them directly into any (relational) query database.
Even though, I’m also looking forward to the code generation tool. It’s nice to have a parseable source file from which you can generate what is in fact your application API: commands and events. I’m looking forward to seeing it at work.
Cheers,
Allard
Hi Allard,
Yes you are right. Using value objects reduces the number
of commands and events which helps. More importantly it
reveals the domain objects in a natural way.
Regarding parsing the domain model to generate command-
and event-interfaces, it is a great idea and it may be doable.
In your example, DoSomethingCommand is normally a method
of one and only one aggregate-root. Using coding by convention,
the parser can find any methods of any AR of the form xxxCommand
and make a command and an event out of each one. The fields of
the command and the event are in a way the arguments of the
corresponding AR method.
There are one exception to the above observation. There are
some commands that involve more that one AR. Those methods
are normally defined in a separate package in aService
layer/module. As long as the methods of those service
objects are by convention defined as xxxxCommand, the parser
can find them too and create a command and an event out of
each one of them.
The above is only applicable to the domain-events.
Application- and system-events are different stories.
But, yes I know. It is easier said than done. Just
thinking out-loud.
Regards,
Esfand
Nice! (Mouth watering.)
Can't wait to see the screen-shots, and I'm heading
to your given links.
Thanks.
Esfand
Hi Esfand,
Here are the screenshots:
http://www.fuin.org/files/metacqrs/screenshot-project-tree.png
http://www.fuin.org/files/metacqrs/screenshot-create-property.png
http://www.fuin.org/files/metacqrs/screenshot-create-operation.png
It's still far from being complete, but I hope to reach the first
state ("generating the generator") soon.
Cheers,
Michael
Hi Allard,
It's nice to have a parseable source file from which you can
generate what is in fact your application API: commands and
events.
That's the cool thing about my little "Meta CQRS" project - It has no
source file! It's just a normal CQRS/Event Sourcing application as any
other. You only work on the "Meta Model" of a CQRS application.
Generation will simply be done by using queries. Of course it wouldn't
be a big issue to generate a text model (UML XMI for example) from it.
Cheers,
Michael
Ah, I saw some XML lately and thought that was your input-file. But the screenshots show that you have moved beyond that! Pretty cool stuff. Too bad Eclipe is not my IDE of choice.
Keep up the cool stuff!
Cheers,
Allard
Hmm… I’m a bit confused as it seems. I got confused with another code generation tool I have seen around. That one was eclipse based. Must be the icons that confused me.
I think a tool like this just to get started on the project could be very helpul. Even if it only generates empty aggregates (with the command methods), commands and events, it could save quite a bit of work.
Cheers,
Allard
Brilliant. Two birds with one stone - Axon sample and
axon/CQRS code generator.
Here is my wish item:
Please allow bulk-loading of meta-model using the current
XML format or any other format you see fit, in addition
to the manual data-entry using the swing client.
This would enable me (and perhaps others) to generate the
code from/using the existing MySQL database's schema (in
my my case.)
I'm thinking of adding the additional data-items your
code-generator requires as a JASON variable added as a
COMMENT expression to each column of the tables. Then
it is easy to use any available code-generators and
create the bulk-input files your system requires.
Please count me in as a early
Regards
Esfand
Hi Alllard,
Hmm... I'm a bit confused as it seems. I got confused with another code
generation tool I have seen around. That one was eclipse based. Must be the
icons that confused me.
Yeah, it's just a simple Swing application and NOT Eclipse based.
I think a tool like this just to get started on the project could be very
helpul. Even if it only generates empty aggregates (with the command
methods), commands and events, it could save quite a bit of work.
Most of the generated code will be abstract classes that can be easily
extended by the developer. This way you can focus on the real
development part. In general I'll try to keep the generation process
separate. This way every style of programming will be supported
through customizing the templates. My plan is even to keep it as
language agnostic as possible (C# may be an interesting addition later
on). The meta model will concentrate on defining what makes up the
CQRS architecture and not what is generated from this model.
Cheers,
Michael
Hi Esfand,
Here is my wish item:
Please allow bulk-loading of meta-model using the current
XML format or any other format you see fit, in addition
to the manual data-entry using the swing client.
Hmmm... I have to think about how to realize this. In fact creating a
model is just a series of commands that lead to events stored in the
event source. A solution would require kind of firing a series of
commands from an XML structure or other external data format...
I'm thinking of adding the additional data-items your
code-generator requires as a JASON variable added as a
COMMENT expression to each column of the tables. Then
it is easy to use any available code-generators and
create the bulk-input files your system requires.
I thought about adding a list of custom tags that could be attached to
any level of Meta Objects (commands, events, properties...). This way
you could add any information that is useful later in the generation
process.
Cheers,
Michael
> I'm thinking of adding the additional data-items your
> code-generator requires as a JASON variable added as a
> COMMENT expression to each column of the tables. Then
> it is easy to use any available code-generators and
> create the bulk-input files your system requires.
Sorry, got you wrong... You talked about the INPUT for importing your
stuff into the Meta CQRS model...
Exactly!
Sorry I wasn't clear. By tables and fields I meant
the SQL tables and columns in my legacy application.
GUI interface is really nice and useful. But, in
certain cases when the number of tables/columns/etc.
is large and there happened to be a way of generating
the necessary data for for the Meta-CQRS to have a
faster/easier start and then using the Meta-CQRS's Swing
GUI, the meta-model can be finalized.
Regards,
Esfand