Domain-Driven Design in Kraków

The beautiful thing in IT world is, that people are willing to share their knowledge. That's why we write blogs, speak at conferences and form local communities.

There are already couple of such communities in Kraków. Sometimes I think, that this city is really the Sillicon Valley of Poland (and maybe even of this part of Europe). There is SCKRK (Software Craftsmanship in Kraków) for software craftsmen, there are many PJUG (Polish Java User Group) meetings for Java people, KGD.NET (Kraków's Group for Developers .NET) for .NET people, Lambda Lounge for functional languages enthusiasts, Bright talks, Kraków Scala User Group, DataKRK, Hacker Space, JAR Camps and many others.

If you are in Kraków, you can always check what is going on today and come to learn and share some knowledge.

On the other hand, there are communities around the world, which are about Domain-Driven Design in particular. The other day I thought, that maybe we can do something similar in Kraków... My current company really liked the idea and decided to become a sponsor - so here we are:

DDD-KRK - meetup for Domain-Driven Designers in Kraków.

We are going to meet once a month - the plan is to make it always the first Tuesday, but the very first meeting was another day and the second will also be on different day. :) I received many wishes and congratulations from other communities in other cities. Thanks for that!

For the first meeting I prepared a presentation about introduction to DDD, and then we started a discussion about business value of it. I hope people enjoyed it. There are some photos on the event page.

The second meeting is going to be really great. At May 6th-9th there will be Implementing Domain-Driven Design workshops with Vaughn Vernon in Kraków. After the last day (Thu) we will have DDD-KRK meeting and Vaughn with Alberto Brandolini decided to give some talks to the fresh formed community. Again, thanks for that!

So... If you are reading this and you know something more about DDD, and you are willing to share your thoughts, and... you know you will be in Kraków someday, do not hesitate to contact me, and we will figure out how to find you some audience. ;)

If you are not that familiar with DDD yet, but you are willing to dig into the topic, join our community - become a Domain-Driven Designer and participate in our meetings.

My 3 cents on 33rd Degree 2013 Conference

Last week I attended, for the third time, the 33rd Degree Conference. This time I had an opportunity to give a talk by myself, so I was able to take another look at the event. I met some old friends and some new people too. I listened to inspiring talks and to couple of boring too. We also had some great talk till the late night at the first day. This was a good event. I only lack some party, like the one, that for example, usually during Java Developers Day takes place.

As the year ago, I decided to give some subjective marks for each presentation. And by subjective I mean, that notes were taken only be me, according to my perception, my knowledge and my sense only. There was nothing personal in them, so please treat them appropriately. :)

Axon 2.0 released

In the CQRS world people don't like frameworks. People like to concentrate on the domain and on customer's problems. This is really great, but in the end you have to write some code to handle command, load aggregate, or save and dispatch events. Long story short, you need an infrastructure.

Although it is not that hard, to write this code, it is still the code that has to be written, tested, and maintained. There can also be some tricky places - especially if you have to distribute the system, or implement sagas. So, why bother with that, if we can take someting of the shelf, and just use it in our system? If the framework does his job, is flexible and does not deny things that we need, I would recommend to use it. It allows us to concentrate on the business problem. Of course, if you use the right tool for the job.

I mention that, because there was a major release of Axon Framework 2.0 couple of days ago. This is a Java open-source framework for CQRS and/or Event Sourcing based applications, but not only.

What we can find in Axon 2.0?

I have been using Axon 1.3 with success, and it really helped me with the infrastructure. In the 2.0 version, there are some improvements, which can make this framework even more usable. The new version has added easier API, performance improvements, out of the box scalability support, and MongoDB-based event store implementation.

Let's take a closer look at the framework capabilities.

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.

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?  

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). ;)

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: