Eventually Inconsistent

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 K...

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

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 E...

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 th...

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 simp...

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 ju...