DDD Europe 2017 — my take aways

Last week I was attending Domain-Driven Design Europe 2017 with my colleagues from Gumtree. The conference itself was well organised, the schedule was full of big names from the industry.

Some further reading about Domain-Driven-Design.

Let me share two of my favourites…

1st — Aligning Organisational & Technical Boundaries to Maximise Team Autonomy by Nick Tune

It was not a coincidence that I choose this presentation. We are in the middle of organisational and technological transformation at Gumtree what I will be talking about in an other future post. We are having tough time to reshape our organisation and tech stack to better support business requirements and changing environment. Analysing our potential solutions and their impact, we always end up thinking about Team Autonomy as one of the main factors. It has a huge impact on every aspect of an organisation. There is a clear message in the title of this speech — which is aligned with our goals — and I really wanted to know more about the hows.
The presentation was well organised and it was really enjoyable.

Main take aways:

• There is a common confusion between Domain Boundaries and Flow Charts. They are not interchangeable!!
• There is no rule for identifying boundaries… Although every decision is about better achieving your organisation goal. One good indicator for a good boundary if it minimises the lead time to positive business and customer outcomes
• Use event storming to discover relevant events and commands to understand better your domain and its interconnections
• Align teams with things that change together for business reasons — This is a good indicator for a subdomain.

Other clues which might help to identify subdomains:

• Contextual language (ubiquitous language), certain part of your organisation speaks the same language. They might belong to the same subdomain.
• Who owns business process steps?
• Boundaries need better alignment with the system of work to remove bottlenecks
• Sometimes it is best to optimise for customer-facing autonomy. Align your teams based on how you interact with your customers
• Forget about bounded contexts and microservices — think autonomy contexts
• Optimise for customer responsiveness
• Finding, fine-graining subdomains is always an iterative process!!

Autonomy contexts — forget bounded contexts and microservices

If I have to provide one sentence to summary this presentation it would be this:

Team Autonomy is maximising our ability to frequently deliver value to customers.

Nick also recommended his own book “Patterns, Principles and Practices of Domain-Driven-Design” which I definitely will read to sink my teeth into DDD more.

Further reading

2nd — Refactoring to Deeper Insight: Lessons Learned Applying DDD to Large Scale by Paul Rayner

Based on the talk’s title I expected something different but in the end it turned to be a good decision to attend. The reason for this is that it was about how to turn your old big ball of mud to a well structured, better performing application with rich domain model and clear boundaries.

He started his talk with setting the scene with Nexia’s old architecture then we were shown some code examples highlighting the problematic parts of them. Some of them reminded me to our very own codebase. Faded boundaries, not clear responsibilities just to mention some of them… It doesn’t mean that all of our services like this but be honest with yourself. If you look around thoroughly in your repository you most likely will find something similar as well. ;)

Main take aways:

• You don’t have to redesign/rewrite your application from scratch to make the boundaries more well defined. Start thinking in small refactorings
• Look for early wins. It builds trust, credibility and momentum
• Rearranging code is an easy-but powerful-design tool, which might be scary if you don’t have good test coverage
• With refactoring you will have better understanding about your domain

Changing the code step by step he ended up having a much cleaner design with well defined responsibilities. I liked this presentation since I am very much following the same principle in my daily work as well.

Just because you can’t fix everything, doesn’t mean you can’t make a difference!

If you have a big ball of mud then don’t complain too much. Start making a difference!!