Tuesday, September 4, 2018

Hello SegFault Wrocław

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!

I will have another announcement soon, so stay tuned...

Thursday, March 2, 2017

DDD Aggregates vs "Life beyond Distributed Transactions"

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.

Monday, September 12, 2016

Two years of domain knowledge crunching

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 before - even automate some pieces of work, but it was hard to use and, after all, not good enough for the market.

In order to expand the market and gain new customers for the XTRF company, the platform required something more - something easier and more efficient to use. They decided to rewrite the heart of the platform - the project management part - the Core Domain.

Long story short

I was leading this project from the very beginning. Back then, I had my team of highly skilled developers and a UX designer, who was outlining the vision of what we were building. 

At that time, I was thinking that translation project management domain could not be that hard, and this one team was able to provide production-ready, and what was more important - market-ready solution, in couple of months.

Now, two years later, with peak of 7 development teams and 3 UX designers involved simultaneously in the project, I am much more realistic. 

Now I know, that at the very beginning I was right - the domain of translation project management itself was not that hard. The thing I did not realize back then - it was not the Core Domain...

Translation Projects

Managing translation project is rather simple - you have to find vendors that will translate source files, then you have to arrange schedule, dispatch files, and fill out finances. Additionally, it almost always involves integration with third-party software: Computer-Assisted Translation tools - aka. CAT tools.

Of course, you can manage all of that without specialized software - with little help of Google Spreadsheets for instance. The only problem is that in this case you have to do everything manually - keeping information about your vendors, sending files and instructions via email, taking care of maintaining translation quality and deadlines by calling vendors by phone, etc.

To make your life simpler, couple of years ago, XTRF provided a platform to perform all of those tasks in one single system. Much faster and with better results.

But there was still a lot of work that had to be done by translation Project Manager. Things like searching for vendors, scheduling dates of projects, and others.

The real Core Domain

The real game-changer in translation project management domain is automation. I realized that about year ago, after I had crunched enough domain knowledge. 

The real Core Domain in that field is making automated decisions for translation project manager - so that she does not have to do anything, except for monitoring the progress.

It took me some time to come up with this conclusion, but, as Alberto Brandolini stated once:
"Software development is a learning process. Working code is a side effect".

So, the learning process took place and the side effect has been officially released.
Spread the word!

Monday, August 4, 2014

Help! I'm stuck with DDD Modeling! 8 Tips'n'Tricks to move on.

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 You still cannot find the solution...

I assume, that You are a good scout, and You did Your homework.
  • You have a Context Map somewhere,
  • You did some Event Storming (by Alberto Brandolini),
  • You are focused on some specific Subdomain and have abstracted unimportant things,
  • You have some significant Scenarios in it,
  • You have some Models that fullfill some of those Scenarios,
  • You are actively using Modeling Whirlpool

Everything looks good, but it seems like You can always come with another significant Scenario that will break some already created Models... You are clearly missing some concept and you need to do something different to stop spinning your wheels. 

You need some...

Modeling Tips'n'Tricks

Enter the 8 Tips'n'Tricks that can help You to move on with Modeling activity. I already knew the first 7 and the last one was proposed to me by Mathias Verraes in the Twitter thread. Here You have it, you can take them and use in Your projects.

Monday, February 17, 2014

Well, hello @Mock - we meet again

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 even some not that bad unit tests there. Woohoo, lucky me!

I wrote first unit test, run - red of course - so I implemented some simple solution - green - I added another test - red - another simple solution - green - I refactored a little - green. Uncle Bob would be proud!

Then, the time has come to write some more complex case. I realized, that I need some additional service to be injected into mine. It was clear to me, that I needed to mock that service in test, so I wrote
private AdditionalService additionalService;
and it felt weird... :/

I realised, that I haven't use mocks for a long time. I just didn't have to.

Thursday, January 2, 2014

2013 summary - books, presentations, trainings, etc.

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 book at all, but for me it was a game-changer. It is full of concrete ideas how to master your body - loose weight, gain strength, sleep better and so on. But the biggest thing was the idea to properly set goals, measurements and persist in the way to achieve them. A lot of technical or management people write about the same concepts, but I was able to grasp them finally, thanks to Tim and this totally different domain - human body.
  • "4 Hour Workweek" by Tim Ferriss - after finishing "4 Hour Body" and achieving my goals inspired by it, I decided to dig more into Tim's work - I bought his first book, and took it on my vacation (I love reading on a beach). Tim also writes how to settle goals and achieve them, but a little different kind of goals. The idea of living your life right now and not waiting for retirement is very tempting... and maybe even possible. I will experiment and try some more tricks from this book in the upcoming year.

Monday, June 10, 2013

Do your aggregates touch each others' private parts?

Most of current programming languages support access modifiers. I cannot imagine any contemporary language, which would not allow the developer to protect access to classes, methods, fields, or functions. Without them, we would not be able to maintain abstractions and encapsulation.

In Java, there are four modifiers: public, protected, default, and private, in C# there is additonal concept of internal, which reffers to assembly, and in Scala, there are possibilities to fine-tune the scope with scoped private and scoped protected modifiers. Other languages, like C++, or F# for instance, also give us some possibility to modify access. They may vary from language to language, but the idea is the same - to protect parts of the code.
(Actually, in C++ there is also a concept of friend, so that other class can get some private access to another class - hence the comment, that in C++ friends can touch each others' private parts... ;)  )

Looking from the time perspective, I can observe certain regularity. The default modifier (usualy without any keywords) tends to be more public for younger languages. By this I mean, that default access in older languages (like C++) was ment to be private. In Java, which is a little more modern language, when You use no access modifying keyword, You will be able to access that code from the package. And finally, in very young languages like Scala (and in F#, I believe), no access modifying keyword means, that the code is public. Why is that? I do not know. I can only guess, but I personally like the Scala way.

OK, let's go back to Domain-Driven Design...