Read on to find out more.

About the Axon Framework

Axon Framework helps build scalable, extensible and maintainable applications by supporting developers apply the Command Query Responsibility Segregation (CQRS) architectural pattern. It does so by providing implementations, sometimes complete, sometimes abstract, of the most important building blocks, such as aggregates, repositories and event the bus – the dispatching mechanism for events. Furthermore, Axon provides annotation support, which allows you to build aggregates and event listeners without tying your code to Axon specific logic. This allows you to focus on your business logic, instead of the plumbing, and helps you makes your code easier to test in isolation.

Features available in 0.4

We have made quite a few additions and changes since the 0.3 release. Unfortunately, this also means I had to make some minor API changes. There is now a bigger choice of abstract classes for most of the building blocks. This allows you to choose whether you want to use the logic provided by Axon, or prefer to develop more of your own. Whatever your wish is, there should be a class to help you on your way.

The biggest change since 0.3 is the addition of an Asynchronous Event Bus that supports transactional processing of events. Since it is asynchronous, it means that your command processing doesn’t have to wait for events to be processed. However, this Event Buss can also guarantee the order in which events are delivered to the event handlers. You can choose full concurrent processing (without any guarantees about ordering), full sequential processing (FiFo guarantee) or anything in between. You could, for example, guarantee the sequential processing of Events that come from the same aggregate.

The Event Bus also provides transaction support. That means you can tell the event bus to retry an event after a certain amount of time when processing fails, for example due to an error in the underlying mechanism, such as a database. For performance reasons, you can configure the event handler to process multiple events within a single transaction. Database updates are a lot faster if you process several events within a single transaction before committing it. Within your event handler, you can configure transactions.

Besides Domain Events, Axon now also allows you to explicitly define two other types of events: Application Events and System Events. Application Event can notify your event listeners that something interesting happened in your application. System Events are a special type of application events and can be used to indicate that a part of your application has changed state, for example when the database is no longer available. These System Events could provide interesting operational information about your application.

Another major change since 0.3 is the documentation. We have brought the documentation up to par with the code-base. All features are now extensively described in the reference guide. You can download the manual from the Axon Framework website: www.axonframework.org.

Last, but definitely not least, we have created a demo application that you can easily download and deploy to have a look at how you can use events to your advantage. This demo application is built using a Flex Client and an Axon-based server side component. The Flex Client registers itself as an event listener and will automatically process incoming events, at real time! That means that you can have 2 windows open, change something in one window, and see the change come in immediately on the other window, too. Check our Sample Installation page for more information.

What to expect in upcoming releases

The major components of the CQRS pattern are already available in the 0.4 release of Axon Framework. However, there is still a number of features we want to include in the 1.0 release. Although one of the advantages of CQRS is that it makes an application scalable and extensible, the 1.0 release of Axon Framework focuses on what happens inside a single JVM. Streaming events between JVM’s is not made impossible though, the Spring Integration connectors can be used to publish events to JMS, MQ, mail, HTTP and any other protocol supported by Spring Integration.

Some features to expect before the 1.0 release are rolling snapshots. When aggregates live for a long time, the number of events to read in each time the aggregate is loaded could easily run in the thousands. Reading in a thousand events takes a long time. Instead of reading in a thousand events, you can summarize all these events into a single snapshot event. Axon Framework will provide the plumbing necessary for you to build snapshot events.

Another feature that we’ll be spending some attention on is failure recovery. Unfortunately, applications sometimes behave unexpectedly and sometimes stop entirely. The reason of a crash won’t be the Axon Framework itself, of course. But since we have a reliable source of events in the events store, we can use this to recover from failure. Axon Framework will provide some building blocks that allow you to republish events to event handlers that did not get the chance to process them. This same mechanism will allow you to restore your application state from backups.

The last feature currently on the roadmap is JMX support. Since Axon Framework deals with the dispatching and invocation of event handlers, it has interesting information about an application’s performance and technical state. We are planning to expose this information using JMX MBeans.

If you have any other ideas, you can submit a feature request on www.axonframework.org/issues.

Getting started with Axon

If you’re eager to get started using Axon Framework for your own application, check out the Axon Framework website. There, you can download the binaries, sources documentation and a sample application. If you use Maven, the reference manual will explain how you can configure the dependencies on the Axon binaries.

If the information on the website is not enough to get you started, don’t hesitate to send me a message or post a comment at the bottom of this blog entry.

A special thanks to…

Before I wrap up, I would like to thank Jettro Coenradie for his help on the sample project and the reference documentation. I think the sample turned out into a pretty cool demo environment for some of the advantages that Axon can provide.

Also many thanks to JTeam for the time they allowed me to spend on the project. Without it, I am sure I couldn’t have delivered this release. Thanks!

Command Query Responsibility Segregation (CQRS) is an architectural style that makes a clear distinction between commands that change the application state and queries that expose the application state.

Background

My interest in CQRS was triggered when I saw Greg Young explain “State Transitions in Domain-Driven Design” on InfoQ. In this interview, Greg explains how he sees that application would benefit from using separate models for state validation and transition on one side and maintaining a view on the current state on the other.

One of the problems that Greg describes is the fact that a single model is often used for different purposes. It is nicely illustrated by the SQL query below. It shows how the model chosen in the application is not suited for the purpose of providing certain information (messages between users, in this case).

queryBuilder.append(
  "m.*, " +
  "m.origin_participant_id as message_origin_participant_id, " +
  "po.first_name as message_origin_participant_first_name, " +
  "po.avatar as message_origin_participant_avatar, " +
  "po_ua.username as message_origin_participant_username, " +
  "CASE WHEN !isnull(po.fieldworker_project_id) THEN 'fieldworker' WHEN !isnull(po_ap.project_id) THEN 'fundraiser' ELSE 'player' END AS message_origin_participant_type, " +
  "po.city as message_origin_participant_city, " +
  "c.name as message_origin_participant_country, " +
  "pd.first_name as message_destination_participant_first_name, " +
  "pd.avatar as message_destination_participant_avatar, " +
  "pd_ua.username as message_destination_participant_username, " +
  "CASE WHEN !isnull(pd.fieldworker_project_id) THEN 'fieldworker' WHEN !isnull(pd_ap.project_id) THEN 'fundraiser' ELSE 'player' END AS message_destination_participant_type, " +
  "m.destination_participant_id as message_destination_participant_id " +
  "from internal_message m  " +
  "left join player po on m.origin_participant_id = po.id " +
  "left join (select player_id, project_id from ambassador_project where enabled = true group by player_id) po_ap on po_ap.player_id =  po.id " +
  "left join user_account po_ua on po.user_account_id = po_ua.id " +
  "left join country c on po.country_id = c.id " +
  "left join player pd on m.destination_participant_id = pd.id " +
  "left join (select player_id, project_id from ambassador_project where enabled = true group by player_id) pd_ap on pd_ap.player_id =  pd.id " +
  "inner join user_account pd_ua on pd.user_account_id = pd_ua.id " +
  "where m.destination_participant_id = ? "
);

Wouldn’t it be a lot nice to have a query such as the one below instead?

</pre>
SELECT * FROM messages WHERE receiving_participant = ?
<pre>

Achieving such queries is very easy, but doing so without making your model impossible to use for maintaining state integrity and guarding invariants is a lot harder. Well, unless you apply CQRS.

Architecture

The diagram below shows an overview of a typical CQRS architecture.

When a command comes in, it will load an aggregate from the repository and execute certain operations on it. As a result of these operations, the aggregate produces events, which are picked up for storage by the repository and for dispatching by the event bus. The event bus will dispatch each event to all (interested) event handlers. Some of these event handlers will perform actions on other (related) aggregates, some others will update the database tables they manage.

Having handlers update the data in the database means that your tables do not have to be normalized anymore. Instead, CQRS allows you to optimize your tables for the way you want to query them. This makes the data layer processing your queries really simple, and maintainable.

Furthermore, since all state changes are initiated by events, these events become a reliable source for an audit trail. By storing these events, you have an audit trail that you can use to replay the entire application history. Instead of just seeing “current application state” only, you can see all the changes that have led to the current state, providing valuable information trying to find bugs or deal with customer complaints.

Benefits

Matches the natural language used

At first glance, such an architecture might look very complex and over-engineered. However, after taking the first implementation steps, it felt pretty natural. In fact, when you explain the behavior of an application, you use a style that fits CQRS quite nicely: “when an order is approved, we send a confirmation email to the customer”.

Extensibility

Imagine an order management application. With CQRS, you could have an “OrderApproved” event, which is caught by a database updating event handler as well as one that sends an email to the customer with order information. If you later on decide to store the order information in an accounting tool as well, all it takes is adding an event handler that does the accounting integration. And since you can reload historic events as well, you can even reconstruct historic information to put in the accounting table.

Reliable audit trail

As I said above [see section Architecture], the model that is used to process command will generate events. These events are the sole source of state changes for the domain classes. If you want to load an aggregate from persistent storage, it will actually load all the past events of that aggregate. This process is called Event Sourcing. When events become too numerous, you can combine a number of historic events into a single snapshot event. The events that have been combined can then be archived for auditing purposes.

Event Sourcing turns your event storage into an extremely reliable audit trail. The events do no only show what happened and when, but they will also reveal the intention a user had. Not only is it an audit trail that will never move out-of-sync with your application, you can use the audit trail to actually replay all actions in the application. Events are not just a notification of state change, they are also the source of state change.

Transparent distributed processing

When using events as the trigger for state changes, you can easily distribute your application over multiple processing units (servers, JVM’s, whatever). Events can easily be serialized and sent from one server to another over JMS, via the file system or even email. The Spring Integration framework –a messaging framework – fits nicely with the event processing concept.

You could even let certain types of aggregates live on dedicated machines. This allows you to choose different SLA’s for different parts of you application, such as giving order creation a higher priority than sales reporting.

Performance and Scalability

Since event handling is done asynchronously, a user does not have to wait for all changes to be applied. Especially when integrating with external systems, this can improve liveness of an application significantly.

Another aspect of CQRS is that it heavily builds upon BASE (Basic Availability, Soft-state, Eventual consistency) transactions. Although the “eventual” part scares a lot of customers and developers, the price of distributed ACID transactions is one that customer typically resent. In most cases “eventual” is just a matter of several milliseconds. But you’re free to make that seconds, minutes or even hours if your SLA permits it (think of management reports that are only read once a week or month).

Asynchronous analysis

When you build a CQRS style application, all activity in your application is processed using events. This makes it easy to catch these events and monitor them for inconsistent behavior. Event analysis tools like Esper allow you to monitor event streams for patterns that indicate possible fraud.

For example, when you detect that a sudden large number of users has an increased amount of failed login attempts, you could decide to block these accounts for a small period of time. In one of our projects, we use RSA Adaptive Authentication to increase the level of authentication required when someone tries to login on an account that might be the subject of dictionary attacks.

cqrs4j – an open source CQRS Framework

A few days ago, I published the source code of a CQRS framework – cqrs4j – on Google code. This framework aims at reducing the amount of “plumbing” and boilerplate code to a minimum. It also provides integration support for Spring Integration and transactional event processing.

You can find project information, source code and documentation at http://code.google.com/p/cqrs4j/.

[Update: cqrs4j has been renamed to Axon Framework. You can find more information on www.axonframework.org].

Upcoming presentations and events

JTeam organizes monthly Tech Meetings, where interesting technologies are discussed. The January 2010 edition will contain a presentation about CQRS. Registration is required, but free of charge. The tech meeting is held on January 7th in our office in Amsterdam [directions] and starts at 16:00. It includes dinner.  Send us an email if you like to attend.

The DDDnl user group organizes a presentation and discussion session on March 9th, starting at 18:00. It is also held at the JTeam office in Amsterdam [directions]. Attendance requires registration with the DDDnl user group, which is completely free of charge. Visit dddnl.org for more information.

What is DDD?

For those people reading this blog item and think: “What is DDD?“. DDD is an abbreviation for Domain Driven Design. We have been writing about DDD before on this blog: “The misunderstanding of domain driven design“, “Domain Driven Design applied“.

The most important thing to know about DDD is the strong correlation between what the domain expert talks about in his normal working day, the design, the code and the tests. Even when talking about the project during a coffee break, the same language is used. This is what we call the Ubiquitous Language.

Another big part of DDD is creating the model. Since we are going to create a software solution for a problem in the domain, we need a form of simplification of that domain to base the solution on. This simplification is called the Model.

You have to know the context to understand the model. Some concepts of the domain can be important within one context, but not in another. Think about a cinema and a system to support buying a ticket. The ticket buying system needs the concept of a person buying a ticket. The seat allocation system does not need the person, just which seats are taken. Both systems deal with seats and people that want to watch a movie. Within the context of buying you need to have information about the person, within the context of seat allocation you don’t.

The central part of DDD is communication between the domain expert and the developers. The knowledge of the domain expert needs to be used while designing as well as coding a solution for the problem to be solved.

What is custom development?

After this very brief introduction into what DDD is about and what the intentions are, let us discuss custom development. Custom development to me is everything more than having a product that needs to be configured and needs one or two adapters to make the product integrated with other systems. Custom development is about creating a new product. The product should be a perfect fit to the problem of the customer. Compare it to a closet you can buy at one of these big stores like the IKEA. Can be a nice closet, with some doors and drawers. It fits alongside the wall you have in mind, and it can be used for storing things. But you know your neighbor could have the exact same closet. The color could be off, the number of drawers is not exactly what you want. In short, it is not the closet you ever wished for. A solution to this problem could be to go to a carpenter and let him create the best closet you have ever seen. He asks what you want, what you want to use it for and how it must look. After a few months and a lot more money than that closet from the IKEA would have cost, you have the best closet ever.

Before the carpenter starts crafting your closet, he needs to know very well what you want. Often a sales person is between your idea and the carpenter. That sales person not know everything possible about the options that you might have. It could well be that the carpenter cannot create what you want. I personally have an experience in this area, we had a closet that was not what we asked for because the sales did not design the closet in a way the carpenter understood it. They also did not talk about it to verify if this was what I really wanted. More over, I did not talk to the carpenter to explain him what I wanted.

What does this have to do with creating fine software. A lot. When creating custom software you have to talk to the customer about what he wants. We, as software designers, must always talk to the domain expert to learn about the domain (what is the closet going to be used for). Of course this “talk to the domain expert” is also true for package based solutions. The freedom that you have related to custom development is much smaller.

So what is important for a good, custom developed, solution? Of course you need a lot of common best practices like: Continuous Integration, Test Driven Development, Quality control, pair programming and JTeam (sorry could not resist). In itself none of these practices will give the customer what he wants. You need to combine these practices with a good process. At JTeam we strongly believe in light weight agile processes. Our own projects are executed using scrum. To be sure you create the best solution, give the customer a lot of feedback moments. We always work iteratively, or within scrum terms, in sprints.

The final step in creating well developed custom software, is to actually understand what the customer wants, and build exactly that. Wouldn’t it be nice if the customer could actually read the code and help the developers to make it better? Of course it would be nice. The solution to that problem should be obvious by now. We use Domain Driven Design to make that happen. Therefore DDD is not the best thing that a developer can learn, it is the best thing that can happen to the customer. That carpenter would have created a much better closet if he would have consulted the domain expert of his customer. My wife knows very well what she wants to use those drawers for. (In reality most of the stuff in the drawers is from me, but this does make the example better ). If the carpenter would have talked to my wife, we would have a better closet and he would not have given us a discount. He could also have sent us some pictures while he was working on the closet. To give feedback about what you are creating is very important to come with the right custom built solution.

DDD together with Agile practices

I am not going to heavily describe what Agile is about. There are so many resources about being agile that I invite you to use google to find out more about it. Within JTeam we prefer to use Scrum for our projects. We like doing sprints, work with a backlog of items to be done. Just like with DDD, Scrum needs a good involvement of product owners to make it a success. Scrum has the goal to deliver working software every sprint. That is only possible when making small steps. Just like DDD, Scrum works with stories. DDD uses stories to create and verify the model. Scrum uses stories to determine the scope for each sprint, write tests and running software. Both DDD and Scrum use tests to verify if everything works. Scrum uses tests to verify if the story is implemented, DDD uses tests to create a good API. Both prefer to write the tests before the actual code.

To me, agile practices like those from Scrum, strengthen the DDD offering. Together they give the customer what he really wants. If something goes wrong, you notice at least after each sprint. Using the domain expert, the risks for doing something completely wrong are little. Be sure to make it possible to make mistakes. Especially in big custom developed systems, you need to be able to make mistakes to create the best possible solution. Refactoring is part of the agile practices, use it to make the design and code a better reflection of the domain.

Why is DDD the best thing for a customer?

By now you should have a basic idea why DDD is the best thing for a customer to happen in his project. The customer gets a custom made software solution that tackles the biggest problem of his business. Because DDD is such a nice fit with Agile practices, he will have a lot of influence on the process as well as the end product. One thing that I learned by experience is that using DDD, the domain expert can help improve software and to understand what has been created. Let me explain what I mean by an example.

For a friend of mine I am creating a backoffice system for his online store. This backoffice has been in production for quite a few years now. We keep on extending it and every now and than we need to make changes to functionality I have created years ago. Since I am not the perfect programmer (who is?), there are some pieces in the software that are not documented well enough, do not have enough unit tests and are just not clear code. When I started to create the backoffice I did not use DDD. Not all terms I used in the code were the same as my friend uses in his day to day business. When I had to make a change in the workflow of the order, we had a very hard time trying to find out what the process actually was and relate that back to the code. Of course my friend knows exactly how he runs his business, but that was not reflected in the code. So he could not help me to explain what the code does. If I had been closer to the domain in the code, he could have explained me very well what the code has been doing.

To me that is the most important aspect of DDD, make sure that the design and code are based on the domain in a way that the domain expert can help you understand the code. Of course that should not be a reason not to document the code or write crappy code. Since he can only explain the concepts.

What do we need from a customer to make DDD a success?

There are a few things you as a customer must take care of in order to make this DDD thing a success.

• Work with an iterative process, we prefer Scrum.
• Make the domain expert(s) available to the team, preferably face to face, during the complete project.
• Provide a domain expert who can make decisions, not someone who has just started and needs to ask everything himself.
• Make the project a shared effort, preferably not fixed time and fixed budget. Try to come into an environment of trust between customer and supplier where each sprint should be a moment of evaluation of the relationship.

What are the next steps?

Ok, you have read this article. (warning: start commercial part)If you want to learn more, feel free to give us a call. We love to do custom development and we are good at it. We can show you what we have done. One of the things we like to do is have an open discussion with your domain experts to talk about their problems that need to be solved. (end commercial part)

Because we really believe in Domain Driven Design, we have started a user group in the Netherlands. We are looking for members that want to learn more about DDD and/or share their experience with DDD. Have a look at http://www.dddnl.org. We are planning to organize events in the future, if yo have ideas let us know.

There are a lot of other resources to learn about DDD, you can start with the following website.

• http://www.domaindrivendesign.org/ – Home page of the DDD community.
• http://www.dddnl.org – Dutch DDD user group
• http://en.wikipedia.org/wiki/Domain-driven_design – Home page on wikipedia with a lot of links to other resources.

Hope you like the article, feedback is very welcome.

The Stars

Our current physical technology matrix lists the following technologies (in alphabetical order):

Amazon Web Services (AWS)

Amazon Web Services is a collection of web services offered over the internet by amazon.com. The most noteworthy services are:

• Amazon S3 – Cost effective way to redundantly store large amounts of data
• Amazon EC2 – Start / stop virtual private servers on demand via a webservice interface and pay only for the computing power you use

We think it makes sense to use S3 if it fits your needs, it is particularly well suited for backup solutions.

Traditional EC2 uses have been hosting temporary (non critical) infrastructure or performing computationally intensive tasks. For these use cases EC2 is very well suited. As of recently you can assign a server a static IP address and have the ability to persist data through server restarts. This makes EC2 a more attractive choice to consider for hosting a production site. The webservice interface that AWS provides allows you to build a true cloud infrastructure on top of EC2 (e.g. start up another server if the load reaches a certain threshold and stop that server again when the load goes down).

We at JTeam use S3 for our internal and customer backups. Furthermore we use EC2 to host some of our project infrastructure like ScrumWorks, TeamCity, Artifactory and the like. We also use EC2 to host UAT environments for our customers. So far we have not used it to host production environments on it.

Domain Driven Design (DDD)

DDD is not a technology or a methodology. It is a way of thinking and a set of design practices, techniques and principles aimed at accelerating software projects. DDD was pioneered by Eric Evans in his book Domain-Driven Design.

In our opinion DDD is a good way to professionalize the contact with our client / domain expert. It also allows us to shows the benefit of using DDD directly to the client. DDD really fits our way of working (e.g. Agile, close customer contact and fixed budget), because it provides an easy bridge between the customer requirements and the code. It allows the client to almost read the code as it is delivered. Because of this readability, it also is much better fitted to testing and documenting user stories.

Google Web Toolkit (GWT)

GWT is our preferred way to develop advanced RIAs (assuming certain prerequisites like no requirements related to SEO). We use it for developing backend / administrative interfaces in an intuitive manner. The main reason why we prefer to use GWT is that it allows us to build Swing like / fat client applications that run in any web browser. For users, this means no need to install software to run the application, while still getting an intuitive UI. Of course there are several ways to develop RIAs, but GWT has our preference because it allows us to write applications in our preferred language: Java. The added value of this is that we can reuse all of our tools and best practices (e.g. IDE, build environment and TDD).

We have been using GWT for some time now and even wrote a book about it. However, we feel GWT is still innovative and cool, as new features are added with every release and there is still a lot of innovation to do there. Therefore, it is definitely a star technology.

GwToolbox

GWT is a great technology to develop advanced RIA. Anyone experienced with Swing (or GWT) knows that this programing model can act as a double edge sword – on one hand, it is simple and intuitive for Java developers for developing UIs, but on the other hand, when not following adequate design patterns and programming paradigms, even a relatively simple GWT application code base can quickly become messy and unmaintainable. The main goal of GWToolbox is to define best practices and design pattern that aid in developing clean and modular GWT applications. GWToolbox contains 3 main modules:

• IoC: Using simple yet powerful dependency injection, one can maintain a clean code base even for the most complex applications. But DI is not enough – the framework promotes event driven development to the max by providing an infrastructure for application level events. This greatly simplifies the interaction between the different modules/component of the application.
• SpringRpc: This module provide simple support classes to integrate a GWT application with the Spring Framework. Although there are several such integration libraries out there, this module tries to make full use of the latest features in Spring. It uses the component scanning mechanism to pick up services in the application context that should be exposed to the GWT client application. In addition, custom namespaces are defined which simplify development even more.
• Widget: The widget module contains different kind of widgets that can be used to create advance RIAs. There are many widgets out there already, but they are either GPL licensed or not as advance as you typically need.

jQuery

jQuery is just one of those libraries you can’t live without when creating a Web 2.0 website with plain old HTML and Javascript. It is a Javascript library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. Not only that, but it teaches you to write maintainable Javascript code. With a little effort you can do amazing visual things on your website, all the while keeping the code readable and concise. So next to pleasing your customer by creating cool things with jQuery, it actually provides lot of added value to you as a developer too. I can see jQuery play an important role in Web 2.0 development for the upcoming years, but it may have to give ground to the more RIA-oriented technologies like GWT and Flex.

Mockito

Mockito is innovative because it represents the state-of-the-art in Java mocking frameworks. It has taken the best practices and the best ideas pioneered by previous mocking frameworks, and applied these in the best way possible. It allows unit tests to be both more expressive and easier to read. In comparison, EasyMock – another currently popular mocking framework – tends to produce more over-specification, resulting in more brittle tests. Finally Mockito’s idiom is both simple and consistent, making mocking easier to learn for TDD newbies.

As a result, Mockito adds value to our business by helping us make our code more robust and easier to maintain and evolve. In the coming years we expect Mockito to become mainstream, and succeed EasyMock as the de-facto standard Java mocking solution.

Rob van Maris’ blog post titled Easier mocking with Mockito describes how to use Mockito and how it compares to EasyMock.

Scrum

Agile software development is a combination of technical, social and organizational aspects. It requires a matching set of engineering and project management practices. This is where Scrum fits in.
Scrum is a lightweight framework for project management that promotes the Agile Principles. It complements our engineering practices and promotes the same core values (organizational learning, quality, personal development, fun). We have applied Scrum in various projects and like the way it contributes to success factors like transparency, customer involvement, focus, productivity, motivation and self-improvement. On the other hand, Scrum has introduced new challenges regarding how we sell projects and services, how we manage projects and how we manage resources.
There is currenlty a lot of hype surrounding Scrum, and many seem to regard it as a silver bullet. Someday the hype will be over, but by then Agile software development will have become (almost) mainstream.

Solr

Solr is definitely one of the biggest stars (if not *the* biggest). Solr is a Lucene based search server which makes enterprise search available as a service. Not only does it bring together all Lucene/search best practices in one box, but it also extends on Lucene’s basic search functionality with powerful features like faceted classification, statistics, and a powerful and extensible query language. Due to an open and extensible architecture, it is very easy to extend Solr with even more functionality (for example, there’s already an extension which integrates document clustering functionality to search results). Ok, so it’s a powerful search server, but why is it a star? Simply because search is growing big… very big. In the last 2-3 years we’ve witnessed it first hand from our clients. Perhaps it’s the Web 2.0 era, or maybe its the proliferation of information that has grown too big to handle, but more and more companies realize that their products cannot do without a good powerful search functionality. We can honestly say that in the last 2 years more than 85% of the projects we did had some form of search integration requirement, most of which grew with time with features and functionality. Today, Solr (and search in general) sells itself. Solr already started to gain good reputation and if 2 years ago we had to explain companies what Solr is and what it can do for them, today customer already know that Solr is what they want and come to us for our Solr expertise.

Wicket

Wicket is a Java framework for web applications. A big difference compared to many other web frameworks is that it does not require a special language (e.g. JSP), just Java and HTML. Furthermore, Wicket is component oriented. Each component is responsible for only a small piece of a web page. Components are reusable which allows you draw from an extensive collection of existing components. These components come from Wicket itself, but also from the open source community. Of course it is possible to build your own collection. This way of working leads, even for very complicated screens, to highly maintainable applications.

Almost every sentence in the paragraph above indicates why Wicket is cool, innovative and productive. Wicket is actively supported and developed and is therefore an excellent choice into the future.

What is next?

I hope this blog entry gives you some insight into the technologies / methodologies that we at JTeam feel are interesting both from an innovation perspective as well as from an added value perspective. As mentioned before, maintaining this matrix is an ongoing effort, therefore this list is subject to change.
In the future you can expect updates as well as blog posts about the other parts of the technology matrix (which will lead to a lot more controversy ).

In this post, I will elaborate on how Domain Driven Design has helped us build a clean and maintainable application, mainly focusing on some technical and implementation choices that we have made.

DDD Background

Domain Driven Design is really about the way software is developed. Hence, it will say more about the way to get to an implementation than about the actual implementation itself. However, if you do it correctly, you will find some of the DDD principles back in your implementation.

The most important concept in DDD is the “Ubiquitous Language”: the language that is used within the domain by all people involved, such as domain expert (our customer), developers and stakeholders. Since this language is used by everybody, it is best to reflect that language directly –hence without translation– in your code. Since the language will contain both nouns and verbs, this means that you will end up with a Rich Domain Model.

Another really important principle of DDD is “make it explicit”. I can’t even recall how many times Eric Evans said that during the four day training he gave two weeks ago. This means that, for example, every time you come across some relationship between two values, you should assemble these two values and name the combination. This way, you make the relationship between these values explicit and named. This name should either come from the Ubiquitous Language or should be introduced as part of it. Yes, that means no single developer can make up a name for something without consulting the domain expert first.

How this reflects in the implementation

Most people I talk to are curious about how this reflects in the implementation. Some people even seem to reject DDD because it is not really all that different in the implementation. Of course it isn’t, at least, not on first sight.

In the OSIX domain, people can use wireless access points in Libraries to gain access to the Internet using their laptop. To do this, they need to register themselves in a central application, owned and maintained by OSIX. This application serves as a web shop where users can buy credits, it provides administrators to block or enable users and keeps a log of actual time spent online.

This means our domain model implementation contains classes like Library, User and InternetSession. This last one is DDD-implementation wise quite interesting.

We needed to log the time a user logged on and when he logged off again. Hence, our first name for this class was “LogEntry”. Technically, we are just talking about a giant Log with a lot of entries. However, DDD requires that everything is to be made explicit and named according to the Ubiquitous Language. So, we consulted the domain expert. He said he calls it Internet Sessions. A user starts an internet session, and an internet session is ended when a user logs of.

Does it change the implementation of the class much? Not really, except for some different method names, perhaps, nothing is really different. In the end, we’re still programming Java, and the same things need to be done. And if you’re used to Anemic Domain Models, you’ll probably have to get used to the fact that invariants are guarded inside the domain object itself, instead of a service.

So, why is this naming important? First of all, it allows your developers and domain expert to talk the same language, without the need of continuous translation. Secondly, new developers joining the project will easily pick up the language and recognize the concepts in the code. This really showed when we needed to change some developers. The new developer was quickly able to see which functionality had been implemented and which still needed some work. Finally, our client, who has a fair understanding of the Java language, was able to understand our implementation and give us direct feedback.

How about persistence?

Somehow, many people see Domain Driven Design and Rich Domain Model as the same thing. It’s simply not true. A Rich Domain Model is the logical consequence of a DDD project, since everything is made explicit. And making things explicit means providing names, properties and behavior to concepts.

Another assumption often made is that Rich Domain Model means “put all logic in the domain”. Which is also not true. It’s not called a model for nothing. Using a model means you consciously leave things out of your domain, because they are either not relevant or not practical in your implementation.

In the OSIX project, we assigned the responsibility of retrieving and persisting objects to the application layer. This means the application services call on the Repository implementations to retrieve or save objects.

Furthermore, we decided to keep all modifications to the state of Entities inside the scope of the Application Layer. In the implementation, this meant two things. First of all, the Transactional boundary is located on the service layer, meaning that entities leaving the Application Service are detached from the persistence context, meaning that changes will not be seen by the persistence manager and are ignored. Secondly, the service layer will never accept an entity as a parameter. If an entity is needed, the application service will retrieve it based on its identity, which is passed as a parameter instead.

Some of the Application Service interfaces methods look as follows:

InternetSession startSession(final LocalDateTime startTime,
                             final UserName userName,
                             final BranchCode branchCode,
                             final IpAddress ipAddress);

void endSession(final long id,
                final LocalDateTime endTime,
                final BranchCode branchCode);

All method parameters are value objects, and thus immutable, thread safe and the whole shebang. The startSession method returns en entity: InternetSession. If you wish to change the state of that object in a way that is useful to the application, you need to call another method (e.g. endSession) using the identity of the session, a long in this case. (Yes, in the case of “make it explicit”, SessionId would be a better name for it.)

The implementation of this application service is no rocket science either. It contains only little logic, since it delegates most of it to the domain objects themselves.

@Transactional
public void endSession(final long id,
                       final LocalDateTime endTime,
                       final BranchCode branchCode)
               throws NoSuchSessionException {

    InternetSession session = internetSessionRepository.loadSession(id);
    if (!session.getBranchCode().equals(branchCode)) {
        throw new NoSuchSessionException("This session belongs to another Branch");
    }

    if (session.isOpen()) {
        session.closeSession(endTime);
        internetSessionRepository.saveSession(session);
    }
}

Line 7 shows the actual InternetSession entity being retrieved from the repository. In Hibernate/JPA terms this means the entity is attached to the PersistenceContext, and all changes are observed by the persistence manager.

Line 8-10 show some very simple validation logic to prevent sessions from another Branch being closed accidentally.

Line 12-14 do the calls to the actual business logic involving the closing of a session.

You could state that the Application Service is responsible of the orchestration of business logic execution. It doesn’t say anything about what the business logic actually means (e.g. what does it it mean that a session is open?).

Conclusion

In the end, DDD doesn’t really drastically change the way most applications are built. The most important change is the actual naming of objects and methods and the location of the business logic. However, this seemingly subtle change can have a big effect on the maintainability of your application.

Domain Driven Design is mainly about making things explicit, and doing so in the Ubiquitous Language.

In some discussions I recently had with developers as well as other architects, I noticed that Domain Driven Design and Rich Domain Model  are interpreted as “put everything in the domain model”. This means (according to some of them) that each object should have a “save” method to persist its state, external systems calls are initiated by the domain objects, and so on and so forth. I have to agree with them that such an approach would not be practical at all. All it would lead to is bloated domain objects of which the real purpose is hidden in hundreds of lines of boilerplate code. However, I don’t believe that Domain Driven Design is about any of this at all. And looking at Eric Evans’ (the writer of the book Domain Driven Design) sample application, my thoughts are confirmed.

Domain Driven Design is an approach that describes the approach to designing the business layer. It doesn’t say much about the other layers of an application. The main advice is to base the domain model on the language your customer uses: the ubiquitous language. This means that you should not have a method “setAddress” on a Customer instance if your customer talks about “register a relocation”. In fact, the last application I developed hardly contained any setter on any domain instance at all.

You might wonder what happened to the other layers if DDD is really only about the business layers. Well, the service layer is still what it was, although it tends to contain less code. All that is needed in the service layer is to retrieve the correct domain instance(s) from the repository, call the appropriate methods on them and persist their new state by placing them back in the repository. With this approach, the logic of changing the state is located where the state is kept, in the domain object. The application logic, such as persistence, transactions, calling external application, raising application events, is placed in the service layer.

During one of my discussions, somebody pointed out that according to the Domain Driven Design book one should only create a service if the logic cannot be placed in any of the domain objects. Well, the book does say that, but the service the book talks about is not the type of service that you find in the service layer. The book talks about Domain Services. Whether you decide to use one of these services is completely independent of the use of services in the service layer, which are also referred to as application services.

I can conclude that applications where domain driven design has been applied are not really that different from other applications, with the exception of the domain model itself. However, this richer model tends to make applications more maintainable and easier to understand as the model exposes the language that the customer actually uses. So, in the end, Domain Driven Design does not have to be as scary as many people think. It is just, as one of my colleagues pointed out, a set of best practices for Object Oriented design.