At JTeam, we continuously strive for good quality code. The reason is very simple: bad quality code slows down the development process. The small investment pays out in even the simplest of projects.
Measuring code quality is not a matter of a single metric. Instead, software quality has many aspects, some of which can be captured in metrics. Those metrics can be nicely assembled within a single application, which gives a nice overview of the state of an application: Sonar.
On March 1st, Erik Rozendaal will give a presentation about Command Query Responsibility Seggregation (CQRS). Greg Young, one of the masterminds behind CQRS, has confirmed that he will be present during this meetup too. Seems like a good recipe for an interesting evening.
Attendance is free, but registration is required. Read on for details.
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.
Command-Query Responsibility Segregation (CQRS) is slowly but steadily gaining ground as an architecture that helps developers to develop scalable, extensible and maintainable applications. Events play a major role in this architecture, and the way you design these events greatly influence the extensibility of your application.
In this post, I describe some CQRS event basics and design considerations that help keep your application extensible.
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.
Nowadays, companies are hardly ever satisfied with a mere web-presence. No, websites have become true applications in their own right. Instead of being a by-product, most businesses acknowledge that the web offers them a nice channel to do business. However, the demands from the business keeps growing as each company want to be better than its competitors.
The increasing demands from the business have a direct influence on the applications complexity. Each time, especially when joining external projects, I am amazed by the way complexity is dealt with in most applications. “Building software isn’t rocket science”, but sometimes we do seem to make it just as complex.
In this article, I provide some insight in different forms of complexity, and how software development teams can design their application in order to deal with the ever growing demands from the business.
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.
The Welke Magazine has been around for a while now and is a well-established name in the home decoration area. To follow up on the success of their paper version, MediaMij –the company publishing these magazines– decided to expand their position in the market by launching an electronic version, welke.nl. The goal of this website was to give their readers a more interactive experience and allow them to find more products that could be of interest in an intuitive manner.
In this post, I will focus on some technical and organizational topics that were addressed during the project. Read the rest of this entry »
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.