DDD Europe Conference Report - part III

Matthias Noback

In previous articles I’ve already spent a few words on some of the talks I watched at DDD Europe that made quite an impact on my thoughts about software development and design. The design part is often the most philosophical one. Design talks are often less practical. Speakers use metaphors to bring their message across and take note of other disciplines than software engineering to discover useful design principles and heuristics.

Rebecca Wirfs-Brock: Design Matters

The opening keynote of the second day was particularly philosophical. To be honest, I didn’t know Rebecca. She is co-author of several important books on object design: “Designing Object-Oriented Software” and “Object Design: Roles, Responsibilities, and Collaborations”. It should be interesting to take a look at these some time.

Rebecca explained the concept of a heuristic, which is an approach to problem solving. It entails a pragmatic method which might not lead to the best answer, but probably gives you a good-enough answer to use until a better one is needed. She posed the question: how many people are in this room? You could for example count 10 people, then find out how many of those groups of 10 people are in the room. Or you could multiply rows and columns and subtract a certain amount. It’s clear that it won’t give you the correct answer, but if you have all the time in the world, you could simply count attendees one by one.

Heuristics often conflict amongst each other. Picking a single heuristic is also subject to your knowledge of the immediate context (you won’t know everything there is to know). And while you build up experience in the field, you discover which heuristics work best. Everyone has their own list of heuristics based on what they encountered so far.

Of course, you learn from other people about their heuristics. I’ve been thinking about it before, but now I can put words to this: since we all have limited experience in our field (we work in different domains, with different team sizes, using different languages, frameworks and libraries, etc.). I personally feel obliged to share what I found out, what I have learned, in order to save other people some trouble. I know many other people do too, and I strongly encourage the reader to the same thing. I’m thinking about books like Analysis Patterns by Martin Fowler or the book on Docker Swarm by Viktor Farcic, which is obviously a clean reflection of a messy struggle to find out the best way to make it work.

Rebecca teaches an important lesson: our list of heuristics only reflects what is our personal, current State of The Art (SOTA). As an example: when we try to answer the question whether we should develop a rich domain model, an anemic domain model, use Active record, Data mapper or Transaction script - we can only answer that question according to what we currently know, and have experienced. And even if we rely on pattern books like PoEAA or GoF, they only tell so much about the context in which to apply a pattern. It couldn’t be otherwise, since pattern book authors don’t know about the context of the project you are working on right now. So, it would be good to keep developing your own heuristics and: you don’t need to feel bad for not knowing every heuristic yet.

In the last part of the talk Rebecca covered a number of characteristics of lively design, a concept from Christopher Alexander’s work. Apparently, his work is an interesting source of inspiration for software design. I don’t recall most of what Rebecca mentioned towards the end, but remembered one particular idea of “the void”, which referred to the clarity at the center of a piece of software. You won’t find the clarity in the code, since it’s basically clutter around a clear idea, something the creator of the software had in mind and tried to implement by writing code.

Further reading:

Prof. David West: The Past (1968) and Future of Domain (driven) Design

I must admit I’ve read only half of David West’s book Object Thinking - Developer reference but will put it on my reading list again. David had some interesting things to tell, about the history of software engineering and its future.

In his talk, David talks about the “divorce” that happened between “software engineers” and the “business”. In the beginning (in the 1960’s), these were one and the same. No one had had an education in software development. Business people wrote programs; it was part of the job. Eventually “software engineering” as a profession, including its own scientific foundation, was defined. From that moment on, it wasn’t natural anymore for programmers to know all about the domain for which they were writing software.

Direct effects of this dramatic change were: programmers started focussing on requirements (and negotiations). Business people started hating IT people, because they delivered late and inadequate software (because they didn’t understand what they were building and how and by whom it was going to be used). IT started to be something that held businesses back, a necessary evil. And while the business world started adopting “agile” principles in the 80’s, it took many years for the IT industry to follow.

David warns us that our intense focus on the machine, on technology, isn’t productive in the end. Domain-Driven Design, if we want to do it, needs practicing. David taunts us, by saying that “DDD isn’t going to happen”. We like to indulge in interesting technical elements, while, to be successful at design, and in particular domain-driven design, we need to have multiple areas of expertness (and several more areas of shallow knowledge). This is a huge challenge.

First, we need to read other books than just computer books. We need to be ready to take the right decision, take the correct action, in every possible situation. This seems like a super-human thing to accomplish, but David thinks that with a “Zen mind” it is possible to transcend our skills and go to the full breadth.

Further reading:

Nick Tune: Domain Discovery: Business Model Canvas Workshop

I had watched Nick’s talk Strategic and Collaborative Domain-Driven Design in which he mentioned the Business Model Canvas, which seemed to me like an interesting tool to figure out how a business works, what its value proposition is, its customer segments are, etc. This is not language I’m used to using on a day-to-day basis but, what every DDD practicioner will tell you: you have to dive a lot deeper into the business you’re working for. So, I decided to join Nick’s workshop and with my “team” worked on filling in the canvas for an imagined business.

Some of the take-aways:

  • It’s a useful, simple format for understanding a business. In fact I’m going to map my new business on a canvas soon!
  • It’s very hard to make a canvas for an imagined business. Next time I’ll make sure to pick an existing one. Our group had a lot of discussions about things we couldn’t decide in the first place.
  • It is relatively easy to think about useful innovations for a business, once you see it laid out on the canvas.

In short: creating a business model canvas (perhaps with some colleagues) is highly recommended!

Eric Evans: Keynote

The closing keynote of the conference was by Eric Evans. It was a fascinating talk really. He started out with putting some things straight. As developers get in to DDD, they become perfectionists about it. We look for principles, rules, anything to hold onto, since the journey we set out to make is not a calm and safe one. We learn lots of new concepts and want to be certain about things. Should we design a bounded context to align with exactly one subdomain? Should we have a (micro)service per bounded context? As we learn from speakers like Rebecca (who’s talk I described above): it depends. While we try to get it right, we will figure out for ourselves what works well, and what doesn’t. Anyway, we shouldn’t try to do everything right from the start, or do it right once and for all. In fact, this perfectionism about bounded contexts is a bit ironic, because a bounded context is meant to “acknowledge the mess”, and to keep it within boundaries.

Eric continues with a discussion about a peculiar aspect of Java time’s API: adding periods of time to an existing timestamp using the plus() method. Eric shows why this isn’t the right name for the method and offers several suggestions to improve the API. In general, his advice is to “give awkward names to awkward concepts”.

The last topic Eric covers is that of path-dependence. The bridge to this last topic is actually quite subtle. He ends the discussion of the plus() method by talking about how adding periods of time (like “3 months”) is different from adding other periods of time which would in theory amount to the same result (like “2 month”, “1 month”). He ends with the idea that life, as well as software, is path-dependent: where you end up, depends on what the path looked like. One particular pattern in the path of software development using bounded contexts is this:

  1. You work with cohesive teams, and produce coherent bounded contexts.
  2. A reorganization means you’ll split, start sharing code (since you have “already implemented this somewhere else”), then finally trashing the result because it’s not good enough in the end.
  3. From there teams will “bubble off”, work on nice, clean bounded contexts on their own. And eventually you will be back at 1.

Eric finishes by encouraging us to “broaden our aesthetic”. We should appreciate alternative solutions, solutions that may not be good according to our own State-of-the-Art. We should appreciate “legacy” applications more, and admire what a company can accomplish using them. And we shouldn’t get ourselves stuck in the perfectionism that DDD often seems to provoke.

Conclusion

I’ve thoroughly enjoyed Domain-Driven Design Europe 2017 and I can recommend this conference to any software developer. See you next time (I hope)!