On Eventual Consistency and REST

Typically in event-sourced systems (with Command Query Responsibility Segregation) that need to display data to a client, we have three components that must co-operate

  • write model that accepts commands and writes events to its event store
  • read model that accepts events and returns DTOs to a client
  • client (e.g. web browsers) that writes commands to write model and queries read model for DTOs

Read More

My talk about Spring Stream, Event Sourcing and CQRS at spring.io

Last month I did a few talks about leveraging Spring Cloud Stream to create fault tolerant and loosely coupled services that use Event Sourcing and Command Query Responsibility Segregation. Unfortuneatly, none of those was recorded due to technical reasons. But, I also had a great pleasure to had a Google Hangout about those subjects with guys from the Spring team. They liked it up to the point to putting the video online, at their blog page. So if you are interested and have fifty minutes, please leave a comment.

Read More

Event sourcing with CQRS sample revisited

Previously I posted a short note about my sample event sourced application that follows Command Query Responsibility Segregation principle. Today I would like to go a little bit further and describe its particular components and their responsibilities.

Read More

Reliable Domain Events

We already know that domain events are a great tool to integrate different parts of your system (so called bounded contexts) and decouple them. Instead of directly calling outside component, we can notify our infrastructure, which in turn informs interested parties about what has just occurred. This another form of Inversion of Control helps us to achieve our goal. Consider following piece of code:

Read More

spring.io.2015

Last month I had chance to attend an event hosted by spring.io guys, namely conference Spring IO 2015. It was held in Barcelona and gathered 41 speakers, whose talks were around spring framework, groovy, grails and clouds. As a developer, I can hardly live without spring, so this was a perfect chance to enhance my spring-related experience. Although I was not amazed by all of the presented subjects, some talks brought my attention. I would like to quickly summarize one of those.

Read More

Why injecting by constructor should be preffered?

Seeing the famous @VisibleForTesting guava's annotation for the first time made me thinking. Without looking at the implementation I was pretty sure it is magical piece of code which silently makes our properties visibile only in tests without breaking carefully (?) created encapsulation. Later on, I decided to look at the implementation and javadocs. Here goes the latter one:

An annotation that indicates that the visibility of a type or member has been relaxed to make the code testable.

So it becomes useful for developers who write unit tests - which is good, because everyone should do so. But then it hit me. At the same time it's handy for **lazy** ones - which is bad. Let's hear that again - visibility of a type or member has been relaxed to make the code testable. Changing the production code for the sake of tests' simplicity is just fine and in fact, this is among others what tests are intended for. But breaking encapsulation, which is one of the foundations of OOP programming seems like a step too far. In fact, enthusiast of Test Driven Development should be worried - should not the tests themselves lead to proper design? Indeed. They should. And in most cases they probably will, but what if we are to test legacy code or modify already existed tests? Consider this excerpt:

Read More