Expectation about maven archetype

Imported from Google Groups
#1

I am working on issue 87, i.e. creating a maven archetype for a sample
CQRS project with the axon framework. My question concerns the
expectations for such an archetype.

A maven archetype should provide a clear starting ground for any new
project and at therefore at least a very simple demonstrations of all
the relevant techniques. This leaves room for a lot of usability
questions. For example, what should be the granularity of the
archetype? What do you expect of the user interface? Which event
handlers do you expect?

In short: What do you expect of a maven archetype?

#2

Hi Daan,

I would go for a very simple setup with the following components:

A spring context defining the basic architecture:

  • SimpleCommandBus
  • SimpleEventBus
  • the 2 annotation processors (command handler and event handler)
  • JPA event store
  • HSQLDB database

Then, I would just go for some simple components (1 of each) that most projects will deal with:

  • SampleCommandHandler (accepting SampleCommand)
  • SampleAggregate (raising SampleEvent)
  • SampleEventHandler (creating Sample instances in a query database)

You could create a package structure like the following:
org.sampleproject.api (containing the command and event)
org.sampleproject.command (containing aggregate and command handler)
org.sampleproject.query (containing event handler and query objects)

This should give most users a sample and a kick-start in configuring their own project. I wouldn’t focus too much on the web project, since there are already quite a lot of archetypes for that.

What do you think?

Cheers,

Allard

#3

Funny... I started just today creating an example project for Axon and
had exactly the same question...

I created the following four Maven projects:

(NAME)-parent (Parent POM for common settings)
(NAME)-common (Code shared between client and web)
(NAME)-client (Client code for accessing the web application)
(NAME)-web (Web application)

(NAME) = Unique name identifying the application.

If query- and command handling is possibly on different servers it may
be a good idea to split Web into three parts:

(NAME)-parent (Parent POM for common settings)
(NAME)-common (Code shared between client and web)
(NAME)-client (Client code for accessing the web application)
(NAME)-web-common (Code shared between query and command)
(NAME)-web-query (Web application handling queries)
(NAME)-web-command (Web application handling commands)

For my example application I'll use Spring WS (http://
static.springsource.org/spring/docs/2.0.x/reference/remoting.html) -
This may also be a good choice for creating such an Archetype. During
installation the user can choose Hessian or Burlap possible protocols
(Good examples for XML and binary protocols) using a property.

Cheers,
Michael

#4

I think I am on Allard's side.

A full fledged archetype with a working UI would certainly be nice to
have, but it could also distract from the axon framework. Someone who
is conversant in CQRS and the axon framework would certainly benefit,
but to get an impression and an idea how to start a CQRS project with
axon could be overwhelmed.

regards,
Daan

#5

org.sampleproject.api (containing the command and event)
org.sampleproject.command (containing aggregate and command handler)
org.sampleproject.query (containing event handler and query objects)

How do people feel about fairly fine-grained packaging?

Ideally CommandHandlers and EventHandlers would not be accessible from
your web tier, but commands, events and the actual query objects (and
associated queries) would be.

Infact, ideally the web tier would have a different datasource
configured with read-only access to the database from the query side.

OOTB, I feel pretty strongly that the sample should yield some example
tests using the existing fixtures with everything-in-memory wiring.

I'd love to see the actual sample wired together via Spring
Integration (with both buses being a JDBC backed JMS Topic with
durable subscribers).

   JAmes

#6

I would go for a fairly simple “one solution fits most” case. JMS queues are interesting but for most applications overkill. And besides, let’s take one step at a time. Having one doesn’t rule out the other one for the future.

I am currently working on an advanced sample. This sample contains some of the “advanced” building blocks, such as completely separate command handling components, command routers, a message queue for events, etc. That sample could then act as an example to those that need these more high volume and scalability related building blocks.

Cheers,

Allard