Eventually Inconsistent

It's been 3,5 years since I gave the last public talk... Way... too... long... So it has to change. And it will! I invite you to a really  innovative conference  for software architects:  SegFault Wrocław . Let's get back to the basics again. I'm going to be speaking about " Using Domain-Driven Design in legacy systems ". There will be some other experienced speakers, with a lot of knowledge gathered while working on  production systems  (not read from a book), so the event is quite unique. I'm looking forward to meeting you there! PS. I will have another announcement soon, so stay tuned...

Last week, I attended the Software Craftsmanship Kraków meetup, where we discussed "Life beyond Distributed Transactions: an Apostate’s Opinion" article by Pat Helland. Author tries to tackle the problem of almost-infinite scaling of applications. He ignores such issues like high availability on purpose and focuses only on scalability alone. That makes the essay easier to read – even for junior developer. Although the author does not say it explicitly, there are a lot of similarities between presented concepts and Aggregates from Domain-Driven Design . Pat's paper was written in 2007, so my wild guess is that he might have been familiar with Eric's book, which was published in 2004. Since there are still a lot of questions regarding Aggregate's boundaries (and technical difficulties arising around them) in DDD world, I recommend Pat's article as a complementary reading, which takes more infrastructure-oriented approach and may clarify some things.

They say, that experience is something you don't get until just after you need it. This is especially true in the field of Software Development. You may learn something from a blogpost, a book, a presentation, or even by talking to a Domain Expert, but you have to get your hands dirty in order to fully understand a concept. Enter Smart Projects 1.0 Couple of days ago, we have released  version 6.0 of XTRF platform  - a very first system that enables almost full automation of translation project management. The platform contains Smart Projects module in version 1.0, which I was developing for the last two years. In this module, we heavily used all the concepts that I was writing about on this blog for couple of years - Domain-Driven Design , Command Query Responsibility Segregation , and  Event Sourcing  of course - and it is written in  Scala .   The platform itself is not new - it was able to manage translation management projects befor...

I was sitting in front of my laptop with a bunch of paper cards scattered all around me. My desk and my windowsill were covered with printed scenarios on the one side and with handwritten sketches of couple of Models on the opposite one. On the monitor, I was browsing photos of previous Modeling sessions and, from time to time, chatting with my friend - an UX Designer. For last couple of days I was doing the Modeling of a very hard part of our Core Domain. I spoke to Domain Experts in different roles, and I was working closely with the UX Designer, who made a lot of research earlier. I run couple of Modeling sessions - both alone and in groups of 2-5 people. I just couldn't figure out a good enough solution. I was stuck. Do You know that feeling? Have You been in that moment, when you realize, that sometimes Synthesis is not that easy part of the Design process? The moment, when you feel like You are trying to push on a rope? You've done everything correctly, and yet...

tl;dr Since I embraced Domain-Driven Design, I didn't have to use any mock. When in 2011, during Java Developers Day in Kraków, Greg Young stated, that he does not use mocks, I couldn't believe him. I mean, come on! How do you test your code that is dependent on other parts of the code? I was at the very begining of my journey with Domain-Driven Design back then... Couple of days ago, I had to implement something in old part of the system. This part was developed like most systems were couple of years ago (and some are still) - with Anemic Entities and stateless, so called "Services". I didn't want to refactor this whole spaghetti around that place, so I decided to go with this anemic approach and "just be good enough". Since I am a big fan of Test-Driven Development (where it is valuable), I decided to write some test for this service that I was about to touch. Suprisingly, there was a test class for this service, and there were...

At this part of the year, many people summarize their last twelve months. So I will. This year was really busy for me. Especially the second part (hence the lack of my activity on blog). Not to extend, here are the most important things that I achieved this year, which changed my life, and will be affecting the next one for sure. 1. Books I read a lot of books this year, but there are three, that affected me the most "Implementing Domain-Driven Design" by Vaughn Vernon - a must-read for any Developer/Analyst/Architect/Whoever-builds-software - just after Eric's "the Blue Book" (or maybe in the meantime). It clearly describes what Domain-Driven Design is and how to implement it (duh, the title). It also gives a little different view at Eric's definitions - 10 years after his publication - and introduces new concepts, that community added to DDD, like Domain Events. "4 Hour Body" by Tim Ferriss - this is not technical b...