EO-CQRS is a set of components for creating elegant microservices we started to work on just a few weeks ago. The intent was to propose a clean and more maintainable alternative to Spring, Eventuate, Project Reactor, and others. Instead of calling static procedures, creating configuration classes, services, etc. we want to use clean and simple objects, the way they are supposed to be used. Today we will see how Kafka producers and consumers work in an elegant, object-oriented way.

Preferring microservices to monolith architecture means more challenges. Most difficult ones are: distributed transactions, distributed locking, communication via message broker, and of course enabling events. Most of these problems have well-known solutions named patterns. CQRS, Saga, Event sourcing. They all referring to event-driven architecture, and unfortunately, they also increase the complexity of the entire system. So increasing complexity we are making our software less maintainable. Can we design our microservices better?

Do you know what the main purpose of reactive programming? I ask this question mainly when interview software engineers, on projects, that require WebFlux or Reactor skills. Very often I hear that reactive means non-blocking and performant. This is not far away from the truth. But reactive programming has more concepts on top of the non-blocking API.

Nowadays, we live in the era of the open source software. So, we are judged by the projects that we’re doing here. But how to maintain high quality not only in the projects on your GitHub account? Most enterprise software comes with big mess. Successful software architect creates maintainable software. In this blog post I will share my key points of successful project, and how to build it from the 1st commit.