This year on Friday 13th of September 2019 I had the chance to join the super nice SoCraTesDay family once more. Like the last two years, the unconference took place at Ergon in Zürich. As usual, the first hour was to built up the schedule for the day. I had a chance to attend to the sessions listed below. This was once more a really inspiring day that gave me a lot of inputs and ideas. It also gave me different views on situations we all face quite often.

Breaking the monolith apart

In this first session I learned a lot how others break a big ball of mud apart. There are nice approaches to structure the code in components and introduce some namespace rules. In the next step, you could design the contract interfaces between these components to encapsulate the logic of it. But even if you have all nice and clean prepared does not mean you have to split it out of the monolith.

There are many things to consider. For example, a in-process method call is cheap. But as soon as you force the call to make a service https hop, it gets way more expensive. This might affect the runtime of the callers and slow down some business processes. Therefore it is crucial to understand all the impacts such a change might have.

One of the big challenges is the separation of the database. At some point you have to find a way to start emitting events, even from the old code. But often, you are unable to find all places where some data get modified. This is when you have to find a way to attach to the database and detect the changes directly to generate the appropriate events.

I had the chance to learn a lot here and recognize many of the problems I already faced or I am currently facing.

Pitfalls and issues with micro services

I did a spontaneous session by talking about “recovering from a microservice megadesaster”. I could join the session with Silvio who wanted to talk about the pitfalls and problems that lead to a microservice mess.

This session was a great discussion about problems you face when you build a micro service environment with eventual consistent data. There are solutions for mostly every issue that may arise. Some could be worked around by different user experience and process models.

Then I explained why we revert from micro services and go back to a more monolithic system. The discussion also encouraged me to go on with our revert to one service. Even by reverting the microservice architecture, we do not want to eliminate all of it. There are obvious tasks, where it really helps. We keep all communication to external systems separated to keep our core domain free of this clutter. We also keep the concept of triggering stuff using events. But we would not go the route down to event sourcing.

The session was a great discussion about pro and cons of a microservice architecture. It feels good not being the only one fighting with this topic.


This talk was absolutely not what I expected but it was absolutely great. It really shows where IT often sucks and what the problem is. It is about using different tools, methodologies depending on where you are. It gives hints when to invest more in quality and where you simply should skip testing at all.

If you just do a prototype, do not try to keep the code or results of it. Just throw it away after your tests. What you should keep is the learning. The goal is to learn and understand the domain or the problem. This is the value you gain from a prototype.

I saw myself in so many places there and all the mistakes I did during my 20 years in this industry.

To get more information to this topic, visit

Clean code + DDD + MVC

Next I attended the session of a friend of mine Marc Dürst. He presented his learnings during implementing the clean code architecture and DDD within a MVC solution. He wrote this as a hobby project. As we already talked about this topic, there was not much new for me, but we had a really nice discussion about some specific implementation details.

This is due to a lot of the guidelines found in the clean architecture book is not that easy to interpret and implement. There are many points not that clear or leave room for interpretation and different solutions.

We also talked about a little less strict implementation of the clean code like I use on a daily bases at work. We did weaken some borders a lot and adapted the architecture to keep the separation and rings but reduce the amount of code or duplication of data transfer objects in many situations.

Agile vs Scrum

Finally I joined the session about Agile and Scrum. It was a discussion about the good parts of Scrum and the things that do not seem to provide that much value or cause trouble.

We shared the understanding of the good parts like refinements, retrospectives, backlogs, etc. What came up as an issue was the “Sprint” even if Scrum weakened this statement already. We discussed about the effect to “finish all items in the sprint” on code quality. We also learned, that a fixed scope is really not happening and that unexpected interruptions are one of the biggest issues.

So Scrum does often not take care of the reality you face when doing daily business. It also looks like Scrum is not the best process when really practicing devops. Another issue is that this kind of process forces the people to be at the same collocated places. This does not go well with remote working and part time jobs.

In the second part of the session, we learned about the Caretaker model, that keeps most of the good parts of Scrum and gets rid of the parts not really needed. It is a different approach where you have to take care of a work item. As caretaker you ask the questions, organize help from the team. You are responsible for the given item from start to the end.

There are some risks by working with the caretaker model but they should be manageable if you are able to have a good team spirit where pair sessions are the normal, not the special case.

There is a blogpost at