I recently read Clean Architecture by Robert C. Martin. The book gives a simple advice: don’t depend on details! For Uncle Bob details are things like the database or message broker. Your architecture shouldn’t depend on the actual implementation of those details. Whether you are using Oracle, MySQL or DynamoDB, whether it’s ActiveMQ, Kinesis or an in-memory Guava event bus - your architecture shouldn’t be affected.

Three years ago I wrote a blog post with the title Don’t use Optionals for data repositories. The post received a couple of critical comments and I had the feeling that I didn’t make my point clear.

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.