Currently we can observe three mega-drivers that force IT into a dramatic change:
- Economic darwinism
- Disruptive technology
All of them are extremely important and the companies that ignore these drivers will sooner or later fall short of their competitors (at least as long as the companies live in an efficient market – non-efficient markets are a different story).
Let’s begin with the first driver and start with a quick explanation: “Darwinism” in short means “Survival of the fittest” – and the “fittest” is not the strongest but whoever can adapt quickly enough to the changing demands of the surrounding environment. (read more…)
…and why it should be a fundamental principle of application design
Some incredibly useful principles or patterns for software design are ignored because of the misconceptions around them, e.g. that they are not useful, too theoretical or their implementation is too complex.
CQRS (Command Query Responsibility Segregation) seems to be one of them. Though being extremely powerful in LOB and collaborative contexts, architects and developers often think that it isn’t useful and easily applicable to their application. But the biggest obstacle for them seems to be the paradigm shift, not the technology.
The reason for this aversion is that this fundamentally very simple pattern is spoiled by many overcomplicating discussions and special technical solutions that are not the pattern’s initial purpose. This short article tries to clear up the misunderstandings and aims to show why CQRS should in fact be a fundamental pattern of almost every non-trivial application that handles the writing and reading of data.
It seems that ‘Bounded Context’ (from Eric Evans’ Domain Driven Design) has become one of the terms that have to be included in every microservices talk (along ‘Conway’s Law’, of course). And in fact, it’s an important concept, and although not really hard to understand, there are different approaches to implement relations and communication between bounded contexts. In this blog post I describe how I extended my movie-database system with another bounded context for the concept of movies. I added a non-ROCA self-contained system for shop functionality using AngularJS, grunt, bower on the client side and Spring Boot REST with JPA on the server side, and I am using server side includes (SSI) for integrating the navigation bar into the frontend.
This blog post is a follow-up to ‘Self-Contained Systems and ROCA: A complete example using Spring Boot, Thymeleaf and Bootstrap’, so reading that blog post would probably help to understand this one. It explains the theory behind my movie-database system made up of several self-contained systems using technologies like Spring Boot, Spring MVC, Spring Security, Thymeleaf, Bootstrap, jQuery, nginx and Redis. You can find the sources along with installation directions here on Github. As a small reminder, here is the architecture of the original systems: