Tag Archives: axon

Object Orientation – you’re probably doing it wrong

Is it possible that almost everyone really has no idea that they’re doing it wrong?

If taken literally, and to the extreme, encapsulation means that objects should have no getters or setters, only command methods. If we follow this pattern, then our code becomes a lot simpler and easier to understand. But how then do we write user interfaces? We follow the CQRS pattern, of having two distinct sets of code — one containing our object model which is used for writing, and which contains the true status of our application, and a second containing the information used by the UI. The read-side model is updated by responding to events in the write-side model. As a consequence, we gain the ability to independently tune the performance of the two aspects of the application.

Martin Fowler called this pattern CQRS, but I think it’s more than that — I think that this is object orientation. Having accessor and mutator methods (getters and setters) leads to all sorts of trouble. The kind that encapsulation was designed to fix. A long time ago, the industry jumped onto interfaces as the defacto pattern for implementing encapsulation — after all, you’re not exactly exposing internal representation if you use a method — you can vary the implementation separately from the interface, the getter method, without changing your dependent code — problem solved, right? No, the problem is still very much in effect because this naive approach is still exposing way too many implementation details. It is almost always the case that when we change the implementation, we’ll also change the interface. This is seen very commonly in the java beans approach to OO — a very influential approach that I now believe is retarding engineering practices.

Try the cqrs approach for a while, and you’ll probably find that your code is cleaner and more elegant, and just as importantly, it is easier to maintain, contains fewer defects, and is faster, and therefore, less expensive to develop. All of this adds up to reduced costs, shorter time to market, and reduced risks.

In a typical webapp, the pattern is simple: javascript fires off rest requests to the server for data to display — that’s handled by the read-side, which is optimised to handle these queries. Eventually, the user submits a change that the server needs to know about, so the javascript at the front formulates a command and sends it, along with any appropriate data, to the back end for processing. This command will be processed by the rest controller, which will call a method on an aggregate root object which is responsible for propagating instructions to its subservient parts. While this is happening, events will be raised which are handled by both other parts of the write-side model, and by the read-side model which updates itself to reflect changes made to the write-side model (this is a one-way street — no read-side events are handled on the write-side). When the command processing is complete, the rest server returns the appropriate code to the client, which then issues a request for updated data from the read-side.

This pattern is remarkably simple, but it leads to very clear code and very clear separation of concerns. Rest services provide data to be rendered by the client. Rest services provide command processing interfaces. Write-side models process those commands. Read-side models react to notifications that the model has changed. All independent of each other. Not a getter in sight.

Where I have done this we have had separate databases for the two sides, and we’ve used the excellent Axon framework for the write-side, and the excellent spring-data framework for the read-side. I’d like to have used spring-data-rest, but that’s just not ready yet. We have also used spring-webmvc for our rest controllers.

We build all of this through maven — once — and release it to a common repo. Builds are repeatable, but we don’t care about that — we promote a single built artifact through all of our environments, ensuring that the artifact in production is the one we tested in functional testing, integration, QA, UAT, and Pre-Prod.


I’ve just spent the day implementing a very simple system to convert numbers to words. I’ve used the CQS pattern, and domain driven design constructs, TDD, and lots of other good stuff. I’ll upload the code to github tomorrow, probably, and you can see it. I did this because my client needs an introduction to this approach.

After implementing the system I thought I’d take a look at some cqrs frameworks, to see if they’d actually make my life easier. Of the bunch, Axon is probably the best at the moment, but it isn’t a framework so much as a tool. The difference is that a framework isn’t referenced from your code, but a tool is, and your code has to interact quite strongly with Axon. I’ve knocked up an approach to using axon that uses compile-time-weaving of aspectj advice onto my domain model in order to provide the interaction with the event bus, but because of the way the framework is implemented I’m having trouble removing it’s dependence on inheritance, so for now I’m going to use the framework raw.

To be clear, I’m only really complaining about the intrusion of the framework into the domain model. Anywhere else and I’m fine with it, but I like the domain model to consist purely of pojos, which makes it cleaner, easier to read and understand, easier to maintain, and more reusable.

Thanks to Vaughn Vernon’s excellent book on DDD I have recently come to appreciate referencing objects by id, so I’m willing to accept an ID as a necessary evil within some domain objects, but deep down I’m still not convinced — I prefer to directly reference objects in a simple navigable way, but I’m willing to accept that a lot of problems are solved if you use an ID as a reference, rather than a direct reference.

I grow concerned when I hear people talking about injecting repositories into domain objects. It’s bad enough that some people annotate them with jpa annotations (see how far that gets you when you have to write your objects to two different database schema simultaneously). In CQRS you have at least two persistence mechanisms. The first is the event source, which stores the business events generated by your model. The second is the query-side database, which I am calling the reporting database. The reporting database is structured to meet the specific needs of agents at the periphery of your domain model (most often, a GUI). This database is populated in response to business events. Note that the event source is not a mapping of you domain model to the DB, and neither is the reporting database. Your domain model doesn’t map to a database (typically).

Perhaps the domain itself should be persisted? But, a 3NF DB schema should not be dictating the structure of your domain model. We’re doing OO, our modeling capabilities are constantly hamstrung by the constraints of mapping to a relational db. You could use something to generate storage objects to store, and have something capable of restoring the domain from the storage objects, but most event sourcing frameworks are capable of doing that through simply replaying the event source, so why would you bother?