Tuesday, December 11, 2012

Speaking experience

Been a long time since I last blogged. There were many things happening, which were pulling me away from writing.

One of those things was an opportunity to share my thoughts with a wider group in public. Recently I gave two talks - one in my company, and a second during JavaCamp #11. The second one was filmed and you can watch it below (in polish).

The topic was "Changing the mindset - more object-oriented view at the business domain modeling" and it was based on my series of previous blog posts (links below). I briefly introduced audience into Domain-Driven Design, Command Query Responsibility Segregation and Event Sourcing concepts.

The main thing in my presentation however, was to show how developer's mindset is changing when meets those contemporary techniques. I wanted to emphasize what questions she starts to ask and what things are becoming more important while she goes step by step over this "rope bridge".

Both speeches were well recieved, I think. :) Thanks to all listeners for your time and great discussions during and after the presentation.

Tuesday, October 16, 2012

Should tests influence the production code?

For a very long time I was told that tests should not influence the production code. By this I mean, that we should not change our design only in order to be able to test it. That was quite OK for me, since - you know - test are only tests - the production code is what matters and what drives the design. Tests should just shut up and follow. Right?

Lastly I am flipping the bit and diving into TDD and I must say - this is quite an adventure. At the beginning I was like a babe in the woods. It was not easy to start. Everything was harder - writing code, designing, thinking... I had to firstly write a test, and then the code - everything was upside down - I didn't even have the code to test. Damn! I started to think about basics again, and that... was really refreshing!

The Example

One day I was given a task to figure out changes in history lines of some objects and update the meta-data for each line accordingly - with ids of objects that were changed. For the simplicity of the example let's assume, that those objects were rectangles and I was interested only in their length.

Let's use an example:


As you can see (you have to excuse me my poor Paint skills), the rectangle A was changed only in the first step (transition from A1 to A2), rectangle B was not changed at all and rectangle C was changed only in the second step (transition from C2 to C3). As a result, there should be the id of the rectangle A in the Line 2, and the id of the rectangle C in the Line 3.

The task was not that hard and my very first thought was to create some meta-data generator that would accept a list of Lines and update each of them. Sounds easy, doesn't it?  

Monday, August 13, 2012

5 reasons why we (still) do not like patterns in the heart of software

We like Design Patterns. They make complicated things simpler. Our brains are designed to tackle complexity with them. It is easier to describe something with words "it's like that one thing that you know, but with some differences" than describing it completely from scratch.

All frameworks that we use are full of Patterns and we understand them very well. Decorator here... Chain of responsibility there... Oh, and some old, nasty, huge and extremely overloaded Singleton over there - yup, we use it too... Piece of cake. This is our (developers) well known Domain. We are Domain Experts on that territory and we feel confident there.

The reality

But guess what - this is not the Domain that we are dealing with on daily basis (unless we are working on frameworks of course :P ). Our Domain, which we are struggling with, is about the business that runs our company. We don't need those mentioned Decorators and stuff.

At a glance, it looks like we can just live with some simple bags for data, called entities, mapped to database tables (the Anemic Model). I personally like to call them humorously Records - the great pattern that is borrowed from Turbo Pascal. I think, that Sławek mentioned about it couple of times (in polish). ;)

Tuesday, July 10, 2012

7 lessons learned from launching my DDD/CQRS/ES startup

It's been a month and a half since I wrote the last blog post. This time it was not because I am lazy (although in general I am), but quite the opposite. I was very busy with launching my startup application written after hours at home with my brothers.

For the couple of last weeks, there was the Euro 2012 Cup in Poland and Ukraine, and everybody around me was crazy about the football those days. On the other side, couple of months ago I started to practice Domain Driven Design with Command Query Responsibility Segregation with Event Sourcing. I combined those two and launched my startup as a Facebook application written in this style: "Typer" (at this moment only in Polish).


What were my goals?

From the personal perspective, I wanted to give people some opportunity to have fun - to type scores in their own groups, compete with each other and find out who is the best football specialist.

From the business perspective, I wanted only to generate some traffic and see if it can be profitable in the future.

From the development perspective, I wanted to practice DDD/CQRS/ES, since I do not have enough possibilities to do it on daily basis.

From the management perspective, I wanted to learn how to use my time effectively, and how to lead my small team.

Did I succeed?

I did! Maybe I wasn't able to achieve 100% of goals that I set up, but I am proud of what I did and I am much smarter now. I want to share my thoughts with you, so here I present my 7 lessons learned:

Friday, May 18, 2012

Event Sourcing is like Vector Graphics

I want to emphasize at the outset, that I am not an expert in graphics. 
I just have some basic knowledge, but based on that I was able to coin this parallel.

I assume, that you have some basic knowledge about Event Sourcing and CQRS, but if you don't please refer to this definition or watch Greg Young's mindblowing 6,5h long classes (if you already do have some knowledge, watch this video anyway - it is worth your time).
I also assume that you have some very basic knowledge about Vector Graphics and Raster Graphics.

What is an Event? Stop for a moment and think. Probably you will come up with an answer, that an Event is an Aggregate's state change which occurred. And this is a very good answer indeed.
Guess what. Vectors can depict the state change too! So Events may be treated as Vectors, right?

Below I will write down some similarities that Event Sourcing has with Vector Graphics, and 3rd Normal Form databases have with Raster Graphics.

1. Scaling up.
In Vector Graphics you can scale up the image and it won't lose the quality. The same is with Event Sourcing based application - you can easily scale them up without losing the quality of the code and design.
Have you ever scaled up a completely consistent, built on top of 3rd Normal Form database application? It looks just as scaled up Raster Graphics based image - let's just say "ugly". ;)

Monday, April 23, 2012

Convention over implementation with Spring Data

I think that most of us are familiar with the term "Convention over configuration", but just to remember (from wikipedia):
The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there's a class Sale in the model, the corresponding table in the database is called “sales” by default. It is only if one deviates from this convention, such as calling the table “products_sold”, that one needs to write code regarding these names.
When the convention implemented by the tool you are using matches your desired behavior, you enjoy the benefits without having to write configuration files. When your desired behavior deviates from the implemented convention, then you configure your desired behavior.
For example, the maven project structure uses convention - where our source files, test source files and resources should be placed in order to be compiled, tested and packaged automatically. We save a lot of time, and create potentially less bugs, just by following this simple convention. Of course, if we need something special, we can always overwrite it in a way that we need.


But this is only about configuration... I would like to extend it a little bit and talk about convention over implementation (my own term - at least I haven't seen it anywhere else yet ;) ). So that we could write less code to achieve more, do it faster and with higher quality. I am lazy after all...

Sunday, March 25, 2012

My 3 cents on 33rd Degree Conference


One of the best conferences for Java masters in Poland has ended. The 33rd Degree.
I've been on the previous one and I really enjoyed it. Totally 5/5.



However, this year was a little different. I also liked it, but I think it could be better. Some speakers were inspiring, some were boring. ;)
And some were talking about things that I already know... Maybe I should read less? ;)
So to shortly sum it up - there was not a single mindfuck during this edition. And that's a pity.

I decided to give subjective marks for each presentation that I attended and here they are:

Wednesday, February 22, 2012

CQRS vs DDD popularity

Let's imagine a situation. You are a person that has some time and wants to learn something new. You have two options briefly presented: Domain Driven Design on the one hand and Command Query Responsibility Segregation on the other. What would you choose?

(Before you start reading below, understand that I compare those two concepts only theoretically and I am not taking under consideration how they interact with each other)

For me it would be pretty straightforward - DDD of course. Why? I will explain below.

However for most people that I have met I see the opposite... I still cannot fully understand why, but let's try to investigate a little...

What Google says? 

I made some quick investigation in the Google Trends. I typed "cqrs" and "domain driven design". When I typed "ddd" or "command query responsibility segregation" the results were unreliable.

We can see that DDD was first and at the very beginning it was more popular than CQRS ever. But then it started to fall down.

On the other hand, CQRS gains the momentum. It looks like in the middle of the previous year it overtook DDD.

domain driven design 

1.00
cqrs 

0.38

Monday, February 6, 2012

Changing the mindset - part 4 / 4 - Subtle difference

This is the last article out of the series about changing the mindset. At the beginning we took the Classic approach, and then we introduced three important concepts (in the order):
  1. Domain Driven Design (Modeling the Domain)
  2. Command Query Responsibility Segregation (Segregation of Responsibility)
  3. Event Sourcing (Segregation of Responsibility)
In the previous part we separated our Read and Write Models. We also applied Event Sourcing as a persistence mechanism for Aggregates. We also equipped the Aggregate with behavioral methods only, and got rid of getters.
Everything looks really nice. The Model is clean, verbose, and everything is explicit (as for such a small example). We have one data store for the Write side, and we don’t have to care about distributed transactions. We can even easily provide historical data.

However, if you paste the last piece of code from the previous part to your IDE, you will see that there are many warnings on the fields – "never read locally". You can ignore them and proceed, but you can stay for a moment and think why they appear.

The "aha" moment!



It dawned on me the one day when I was really sleepy. I was making some coffee, while my brain was in the nothing box. And somehow the idea came to my mind - why do I need all those fields?


Monday, January 23, 2012

Changing the mindset - part 3 / 4 - Segregation of Responsibility

In the previous part we created quite verbose object oriented Model of our Domain. The Domain itself is extremely simple, but try to imagine your Model, which you are working on day by day, that would be so explicit. Wouldn't be easier to understand it? Whatever you can do on an object, you do it directly through methods, which names and arguments, comes strictly from the Domain Language. And even those objects' names come from this Language too. Well, this is just OOP done right, isn't it?

There is actually one issue with that approach. We want to show some of the data to the user. And if so, then we have to expose internals. So in addition to our well-crafted, encapsulating behavior methods, we have leaky getters...

Clean the model

Let's do something that may look a little strange for the first time. Remove those getters. For a moment don't think about the View. Doesn't the Model look pure and clean without them? It has only behavior as a boundary.

So, how to generate the View? First of all we have to note, that we may have many Views (screens) looking at the same data from different angles. In classic (anemic) approach we would have one Model and many, many SQL joins. But we can do something different - something more explicit.

We can create another, second Model strictly optimized for each single View. What is more - we can store those Views in some document database (NoSQL), so our reads can become really fast. I won't go into the details with their implementation, since they are fairly simple anemic-like classes created for each particular View.

So we will have the Write side (modeled in terms of Ubiquitous Language, with strong boundaries definition), and the Read side (modeled as classic anemic entities highly optimized for particular Views). Both sides will be fully separated and responsible for different user actions.

Probably you are wondering - how to feed those Views with data? If we are using single SQL database, we can just create database views and map them to View classes with some ORM. But if we use many data storages, then we have to make something different.

Monday, January 16, 2012

Changing the mindset - part 2 / 4 - Modeling the Domain

In the previous part we created Anemic Entity Match which was connected to another Anemic Entity Team, and they both were ruled by a Service MatchService. We had a bunch of getters and setters in them, which could be executed from any place that we can imagine. We didn't have any behavior in our domain objects.

As I previously said, it can be a very good approach... Of course, if you are writing your code in C or Pascal... ;) After all - doesn't those, so called, Entities look like structures or records? And please do not tell me, that getters and setters are encapsulating the state...

If we consider ourselves to be Object Oriented Programmers, than we have to start thinking differently. It is not enough to make our objects out of data. We have to teach them how to act.

Where to start?

OK, so we want to start changing the way we think to more Object Oriented, but where should we begin? If we cannot just define the data and put it into structures, where to search for the clues?

The answer is closer than we think. We use it day by day. It is our language. And more specifically - so called Ubiquitous Language.


We have to examine the words that we are using to describe Processes that takes place in Modeled Domain. We should talk to people, who have the deepest knowledge about the Domain. They are called Domain Experts and they are extremely important for the Modeler.

For the purpose of this series, let's assume that our Domain Expert gave us the deepest knowledge about the Domain in the previous post. Let's take a closer look at it.


Wednesday, January 11, 2012

Changing the mindset - part 1 / 4 - Classic approach

There are a lot of materials how to model Aggregates and Entities in Domain Driven Design. There are also a lot of materials how to manage your Event Stores, when you are applying Command Query Responsibility Segregation with Event Sourcing. And definitely there are a lot of materials how to combine those ideas together.

However, I cannot find any articles about the way that developer’s mindset (and his code) is being changed when he tries to leave the Anemic Domain approach and goes into the deep with all the concepts mentioned above.

So let’s take a closer look at it. I will provide an example and try to depict how my mindset was changed when I was adding new things to my code. I will use a very simple domain and model it in the easiest possible way, so as not to obscure the picture.

This is the first article out of four that I will write in the nearest future, so stay tuned.

One can debate if my approach to modeling the domain is the best, but for this series, I think, is good enough. ;)

The example domain

Let’s think for a moment about very simplified domain for a football match. For you guys – on the other side of the ocean – it's... ...still a football match (it's not a soccer - deal with it!). ;)


We have two teams that will play the match. We don’t know the date of the match at the moment of defining it, but we know which teams will play against each other. We can later setup the match date, but it can be done only until the match is finished. We can once finish the match with a score, but it cannot be finished before its start.

The end user wants to see the match: team names that play, match date if is set, match finish date and score if match was finished.

Monday, January 2, 2012

2011's mindfucks

Do you know what mindfuck is? Quoting the urban dictionary:
An idea or concept that shakes one's previously held beliefs or assumptions about the nature of reality.
I like this definition, but I would widen it a bit. This idea or concept doesn't have to be based on held beliefs nor assumptions. It can also broaden the horizon by introducing something completely new. However this has to really change one's perceiving of the reality. Once you see it, you will not be able to miss it again.


The 2011 has gone and it is a part of the past right now. It is a good moment to stop for a while and look backwards to see what has happened during the last twelve months.

There were two people who messed up in my head in the previous year. I met both on conferences in my home city, Kraków (Cracow).

The first person was Linda Rising. I haven't heard about her before, but she gave such a great prelection on the 33rd Degree, that I decided to dig deeper with her work and I don't regret it.

The second person was Greg Young. I knew him from many publications, videos and podcasts. I was hoping to learn something new and exciting, and I wasn't dissapointed. His workshops during JDD11 were really mindblowing.