CQRS
Command Handlers
The Spring-based HandlersProvider was based on the BeanFactory which is being processed during context refresh. In this process the BeanFactory is scanned for any implementation of CommandHandler interface. Next, these definitions are stored in a registry to map command to handler bean name. CDIHandlersProvider does exactly the same but using the CDI BeanManager. I could not find any reasonable substitute for the 'context refresh' event handler, hence whole process is initialized in the @PostConstruct method.All the command handlers were adnotated with custom @CommandHandlerAnnotation and here I met the first obstacle. In the original implementation, this annotation has following definition:
@Component
@Transactional
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface CommandHandlerAnnotation {
}
Finders
In original solution finders were implemented using JPQL (JpaOrderFinder) or JDBC (SqlProductFinder). First approach is fine since it uses a part of JEE, the second one had to be removed due to its coupling with Spring's NamedParameterJdbcOperations. I decidded to rewrite it with Jpql to keep it simple and consistent, but there is absolutely nothing wrong in writing pure SQL-based implementation even if it's strongly related to particular DB engine. For many purposes such solution is even a better choice. This subject is well covered by the CQRS Query Tier philosophy.If this branch becomes more stable and the database will stay unchanged, I will try to rewrite the product finder with Native SQL.
Events Engine
When I first started to prepare the events engine, I was really glad that JEE6 offered cool and simple API to deal with such matters. If you're not familiar with it, let me give a quick example: @Inject
private Event<SomeDomainEvent> event;
public void doSomeBusiness()
{
// business code here
event.fire(new SomeDomainEvent(someArguments));
}
public void handle(@Observes SomeDomainEvent event)
{
// reaction
}
CDIEventsInitializer: Scans the CDI BeansManager and registers listeners (as names) for events basing on annotations
CDIEventHandler: A wrapper class for instantiating appropriate real handler from the BeanManager
CDIEventPublisher: implementation of ApplicationEventPublisher and DomainEventPublisher that orchestrates handling.
As you can see, nothing new here, just the same idea as in Spring-based implementation rewritten with the BeanManager. Solution re-uses current @EventListener and @EventListeners annotations without adding anything to existing code. Asynchronous event handling is not yet available, but it should not be difficult, probably we could use the EJB 3.1 @Asynchronous annotation.
DDD
Repositories
Due to some experimental purposes the repositories were somewhat modified, but in fact there should be no need to do that. I will try to revert changes in order to bring all the JPA-based repos back to their initial form. To achieve JTA without Spring I added OpenJPA + Derby initialized by TestDBInitializer. There were some problems with Embedded in-memory database, so instead a standard network server was used (data is wiped on startup, refer to persistence.xml).Sagas
Since no changes were needed in event handling API, the SimpleSagaEngine could be left untouched as well. The only thing to do was writing new SagaRegistry implementation, the... yes, CDISagaRegistry. Again, if you take a closer look you will see that it is almost a copy of SpringSagaRegistry using BeanManager instead of BeanFactory.Integration Tests
I must admit that it was my first experiment with Arquillian. I had to learn how to set it up quickly due to very limited free time, so correct me if I made some dumb mistakes in my tests. This runner combined with Glassfish-embedded lets us create a fully functionable JEE sandbox environment where we can deploy our tests and run them automatically. Four tests were prepared:ProductOrderingIT: Known as ProductsOrderingFunctionalTest in trunk
SagaIT: Known as SagaIntegrationTest in trunk
JpqlProductFinderIT: Tests different criterias of the finder against some test data
CDIEventsIT: Tests if the CDI Event dispatching/handling engine works as expected
Let me explain a few details about test names. An integration test verifies some scenario in environment of collaborating objects. Sometimes it checks whole flow between layers, soetimes only cooperation of few elements (like the CDIEventsIT). Another thing is an end-to-end test. Its scope is wider, it verifies application behavior simulating actions of end-users (for example with Selenium). This subject will be explored later after I finish some work with the UI.
The Arquillian runner is an interesting tool that certainly adds a lot of comfort, but there are two disadvantages worth mentioning:
1. The Glassfish-embedded server startup time is significant. If you want to run your test many times with continous refactoring and checking, it's probably slower than deploying the Spring solution on jetty.
2. Deployment must be described by list of classes or packages. I could not find an easy method to deploy "just the whole thing", so I was forced to redeploy many many times before my tests stopped showing the ClassNotFoundException. If you have a tip how to do it (there must be a way...), please let me know.
User Interface
I am not a big fan of tinkering with presentation, styles and all that stuff. With JSF 2.0 + JRebel creating UI is pretty simple and painless. First I spent some time struggling with Resin just to discover that its own JSF implementation is not supported by JRebel. Everything works fine on Glassfish 3.1 Web Profile, so currently I am developing the view layer. You can see first effects committed in the repository, but please remember that it's still just a draft.Coming next
After finishing the application will be re-integrated with JBehave without using Spring. Simultaneously I am thinging about how to decouple @Named and @Stateless bean definitions from classes. As I mentioned before on the discussion board, it is hard to imagine how this branch can be merged into trunk to keep one project and still maintain its simplicity. Probably it will just stay as a fork in a role of proof of concept.Last thing to complete is preparing other entry points for the application: remote, web services, maybe REST? Anyway these subjects are a little bit beyond proving flexibility of framework running the CQRS/DDD architecture of the Leaven.
