At 98elements we highly value Domain Driven Design. We try to apply it to our clients’ projects to show them that paying attention to its core domain makes sense (including fiscal one!). We make our best to teach them that common language used by the whole team (both our & client’s developers, domain experts, PMs, POs, etc.) reduces friction, time & resources needed during development.
That’s why I went to KanDDDinsky conference last year, held as usual in Berlin. I met many people passionate about DDD and I was lucky enough to talk with invited speakers. I’ve also met a bunch of awesome people from Poland as interested in DDD as I am.
All of the talks were taped and are finally available online. I want to highlight the ones I found particularly interesting. Good work should be appreciated and I hope you might be able to watch them (or another talk by the same author) live during some future conference.
Let’s start with the first day, shall we?
Alexey showed his experiments with actor systems and DDD. He argued that one should not conflate business logic and actor code. I really liked his presentation because it resonated with my own thoughts. After designing and implementing couple of complex actor systems at 98elements, I came to conclusion that actors should be treated as an execution environment with well defined characteristics and guarantees whereas business logic should be called by actors, but stay separate. Apparently Alexey shares this perspective. He presented code which is available in his ddd-actors-talk GitHub repository.
Dylan presented his view on how an architect can systematically approach his not-so-easy job by following three main points: making, communicating and reinforcing decisions. He described what each of these general points might entail and what pitfalls can be expected. The whole presentation struck a right balance between being lightweight (Dylan is a really funny guy) and specific (presenting real life obstacles and decisions that were made).
Scott is a well known guy advocating for functional approach towards domain modeling. He discussed how the type system of statically typed language and properly discovered types can help in writing better code and spot mistakes as early as during code compilation. If you’re into functional programming you might have heard about Scott and his blog F# for fun and profit (if you haven’t, I encourage you to read it). His blog is home to classics like “railway-oriented programming” or “designing with types” (his presentation seems to be based on the latter).
Scott is also the author of “Domain Modeling Made Functional” which received very good reviews from my tech colleagues.
Carola gave a fantastic presentation showing in a systematic way general problems the tech industry has faced over the past decades and solutions we have came up with to remedy those problems. I loved the presentation because it was big-picture-oriented - Carola shifted her focus from technicalities to principles. She also mentioned what she predicts to be our future challenges. Overall, I’m definitely going to Carola’s next presentation no matter what it’s going to be about.
As a side note, Carola’s book “Langlebige Software-Architekturen” was highly recommended by some of my smart German tech friends. It recently has been translated to English under the title “Sustainable Software Architecture” - I’ve already ordered it and it’s in my reading queue.
Michael showed how changes and decisions in one bounded context affect the other depending on the relationship between the two. This might not seem like something new, but by using specific examples Michael showed how context maps contain valuable information not found in code. His presentation was very elegant & clean plus it had animations. This contributed to easier understanding of presented topic.
Now, Michael is the author of “Hands-on Domain-driven Design - by example”. I haven’t got a chance to read it yet but if it’s anywhere close to his presentation in terms of being very clean & approachable then it’s definitely worth reading.
On to the second day!
In his presentation he discussed social aspects that drive success or failure of software projects. By using specific examples he argued that culture is a key factor when it comes to achieving success, as is the feeling of purpose, autonomy and mastery. Similarly, he pointed out that bounded contexts are not just units of language consistency but also units of purpose, responsibility and pride.
Adam presented his thoughts about finding the right service boundaries of complex software systems. Specifically, he argued that finding right boundaries is a bottom-up and not a top-down exercise and it should be based on data and behavior. He supported his thought by pointing out that organization boundaries are very often not aligned with service ones which makes picking right boundaries from the start problematic. Furthermore boundaries picked using top-down approach are less likely to stand the test of time - no one sets out to make a mess but over time entropy (e.g. in the form of new features) tends to gradually blur them.
Jimmy is a very experienced (and friendly) guy. He was kind enough to share his thoughts about what matters most when undertaking a software project. He distilled this issue to five key points (“start with purpose”, “business is context”, “focus on language”, “use circle of safety”, “remove bottlenecks”) that he believes are crucial for the project to be successful, people happy & energy spent effectively. He backed each of those points with an anecdote from one of his past projects that probably everyone can relate to. I found Jimmy’s presentation highly valuable as I’ve often wondered myself what characterizes software projects which are successful and Jimmy provided me with (his) answer.
Overall, last year’s KanDDDinsky turned out to be a great chance to talk with people who value Domain-Driven Design; do some networking with cool people; share thoughts & experiences. And so, I’m marking this year’s KanDDDinsky in my calendar.