Hi folks. The New Stack just published my article about CQRS. It is a full story about how, when and why to apply this pattern with various Spring tools. You can find it here. And I did the drawings myself!

Messaging is cool. It allows to deal with a broad set of various problems that developers face on a daily basis. It is not a silver bullet though. One must assess if their architectural drivers fit this pattern. A list of tips that might help you with this decision:

I wrote a post on the spring blog. It is about how to tackle complex enterprises with Event Storming, Spring and DDD. You can find it here

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

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.

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.

In my last post I wrote about domain events publishing. Events were published at the end of aggregate public methods as a natural consequence of internal state modification. Let's look again at this code sample:

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:

Several times lately I came across Spock tests, which conceptually looked as follows:

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.

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: