A few years ago I attended the famous Greg Young’s course (actually, both of them) at SkillsMatter and Greg asked me at the end if I am staying for DDD Exchange. I never heard of the conference before that day and decided that one day I would definitely go. These were those good old days when SkillsMatter was not so large yet and CodaNode was not a thing of reality, but only of Wendy’s dream and imagination…
This year it will be the second time I will attent DDD Exchange conference at SkillsMatter in London. My first time was 2017 and I really liked the atmosphere, the fact that a very good lineup of speakers met rather small but very engaged audience of Domain-Driven Design enthusiasts. I met people I knew and made new friends, which was awesome. The Unconference was something I never experienced before and there I gave my first lightning talk. Before I was only speaking at Norwegian meetups, including DDD Norway, where I am the organiser. This was very engaging and demanding experience!
So, what is it there for me in 2018? Well, now I have some more things to say. In particular, working as a software architect in a rather but very active small product company, I get this feeling that in a development team of any size, as soon as such team is not directly involved in the business, the solutions the team delivers is often not based on knowledge and is not solving the actual problem. Instead, developers base their understanding of a problem on piles of assumptions. They are biased by their own views and previous experience and ignorant to the needs of their users. Cognitive psychology discovered that so-called expert predictions are rarely match the real world because the world is much more complex and people tend to simplify complex and complicated problems to their limited knowledge about it and skills they possess to solve such problems. I feel this is something different from over-engineering, which we definitely need to avoid, but the realisation of the essential domain complexity is fundamental in order to deliver a quality solution. Trying to bend problems to something we did before and using tools that were made to solve different problems, just because we are familiar with them, rarely works, but we keep seeing people making the same mistakes over and over again. I am going to show some weird examples of real-life systems and design thinking that lead to overall awkward user experiences and production failures, and discuss some ways to avoid this.
Interesting enough, classification of complexity, different views on the same problem and cognitive biases are the thing right now. There were several talks about this topic on DDD Europe 2018, including mine. I believe this is caused by the fact that despite we are trying hard to deliver this simple message that Domain-Driven Design is not about tech, too often it is seen as a bunch of design patterns for developers, which DDD is definitely not about. Interesting enough, there is a similar movement in the around-Agile community that proclaims that value is something to be considered the most important delivery. Tom and Kai Gilb are doing a lot in this area right now. Understanding the real problem is the only way to deliver real value and too often we as developers just concentrate on delivering software.
Apart from being busy with stating the obvious, I am also busy delivering designs and code for the company I work at. Here, and in many other places, I see more and more interest in event-sourcing. There were quite a few talks and workshops on DDD Europe 2018 about the topic, including the EventSourcing with C# hands-on that I delivered together with Sérgio Silveira. This topic will be even more hot later this year and in 2019 because the community gets more tools and gains more experience, making this awesome technique easier to use and lowering the entrance barrier.