Last week, I published the 0.4 release of the Axon Framework. Axon helps developers build high performance, scalable and extensible applications using the CQRS pattern. The 0.4 release is a major step towards 1.0, and includes transactional event handling, high-performance caching repositories and easy configuration of event sourcing support. Furthermore, we have also built a demo application that uses Flex to get real-time updates pushed from the server.
Read on to find out more.
Many applications use some form of persistent storage to store its state. However, important information about this state is lost: why is the state as it currently is. Furthermore, a single model is used to store information that is retrieved for many different purposes, often resulting in extremely complex and bog-slow SQL queries.
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.
One of the main things we do @ jteam is creating rock solid custom development. Of course we use proven frameworks, we keep innovating and we use a lot of the best practices for custom software development. Best practices I am talking about are: Continuous Integration, Test Driven Development, Peer reviews and of course Scrum. I guess I could use more buzz words in there, but that is not the scope for this item. So I am not going to talk about cloud, soa, virtualisation to name a few. This post is about why DDD is a match made in heaven with custom development.
In Alef’s previous blog entry about the JTeam Technology Matrix, he explained the basic idea of using a BCG-matrix to classify technologies. In this blog entry I’ll focus on the ‘Star’ section of our current matrix and highlight some of the technologies that are currently in there. Star technologies are the technologies that bring us added value in the projects that we do, but are also cool and innovative to use. Please keep in mind that the content of the matrix is under constant discussion and is subject to change. This overview should therefore be considered a snapshot of today’s matrix.
Read the rest of this entry »
In a recent project for Osix, we developed an application allowing visitors of a library to use the wireless Internet connection available there. Visitors can pay for the Internet access in two ways: an online payment, for example using a credit card or by deducting the amount from their library account. All user accounts, as well as the available products, library configurations and payments are managed from a single central application, called Digital Services Manager.
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.
There seem to be two mainstream approaches in Java application development: the domain driven approach, and the “fat service layer” or Transaction Script approach. As an architect, I’ve been investigating both methodologies by reading about both of them and applying them in real life enterprise projects. It is at the least amusing to see how followers of each approach think of the other. An example of how developers (disappointing to realize that these people are co-developers) react on each other’s approach can be seen in the reactions to Arjen Poutsma’s post.