Update: I updated the example on GitHub to Spring 2.5.X! The latest post on this topic is here.

Updating data is one of the most frequent use-cases in applications. But it might also be a painful task which results in a bunch of ugly code.

Usually we use Spring’s @Configuration to define some special beans. For example a data source:

I recently made my first steps with Kotlin. After exploring the language for a couple of weeks, I tried to translate one of my favorite architectural patterns from my Java background to the Kotlin world - Domain Driven Design.

In my current project, we are using an event-based architecture in order to communicate between services. The events are implemented as JMS messages, which we send over ActiveMQ. Each system sends and listens to multiple events. While sending events is pretty easy, on the listener side we quickly ended up with a class explosion:

Last year, I wrote an article about generating PDFs with Java and Flying Saucer using Thymeleaf HTML templates. The article covered all basic steps to generate a simple (text only) PDF file. However, I got some comments on how to include images or how to style the PDF. So let’s have a look at part 2.

Usually, when we talk about architecture, we talk about the application itself. We think about layers, domain models and interfaces to structure our code. Most of the time the tests will follow this architecture. We create one test per service and mirror our code.

Despite a simple authentication, a lot of applications have a concept of authorisation. A user is not only logged-in, but has a set of roles which allow him to perform certain actions or see certain views. For example a user with the role ADMIN will probably be able to do more things as a user with the role CUSTOMER.

In a distributed environment, services must communicate with each other. One of the most popular ways of communication is messaging. Tools like ActiveMQ, RabbitMQ or Kafka are making it easy to exchange messages between systems. But no matter which broker you are using, you must decide which kind of message you want to send.

During the last days, I dug a little bit into the Saga pattern. The Saga pattern is an architectural pattern which provides an alternative approach to big and long-running ACID transactions. It takes a business process and breaks it down into small isolated steps - each of them with its own transaction. The overall consistency is provided by manually reverting past actions if needed (called compensating).