• Recently I had a chance to participate in Domain-Driven Design (DDD) training hosted by Mike Wojtyna. The training was great and I felt fortunate to be there in the training room. Most of the training focused on Event Storming technique (coming up with business domain events, ordering them into sequences, exploring the boundaries between processes and contexts, applying some heuristics, etc.) Even though I was the only test engineer in the room and the training felt tailored to “closer-to-the-code” roles (tech leads, software architects, etc.), I recognized a lot of testing there. Let me explain. As an observer from the world of “prevention” or “shift (detection) left”, I noticed a lot of potential to prevent issues (like accidental discrepancies resulting in accidental tech-debt or functional accuracy bugs) early while business and engineering were exploring the context map together, “aligning”. In terms of “shifting left”, there is no “lefter” than that to shift. Another thing I really liked is - Event Storming results as a visual deliverable - Context Map. Such visuals (probably, all visuals in general) bring clarity as that level of detail should be understandable to both business and engineering. And clarity is always prevention.
    P.S. if you wanted some recommendation to read more about Domain-Driven Design - Mike recommends this book (more than (or instead of) the blue book or the red book). Also, one can find a lot of useful resources here: https://github.com/ddd-crew.

  • Another technique I found interesting from DDD training was Impact Mapping. Actually, not so long ago I was using a very similar technique to explore my new role and map my efforts to potential impact using Effort-Output-Outcome-Impact sequence. I found such techniques helpful as in many cases drawing such maps on your own and discussing such visuals with others can bring interesting ideas and shifts in understanding and priorities.

  • And once one has an Impact Map, then they are only a few steps away from composing a Wardley Map. Compared to Impact Map, Wardley Map adds an Evolution dimension (genesis, custom built, product/rental, commodity) to the mix allowing us to distinguish our product’s core domains from supporting domains. Some say it can be used in strategic planning to speculate about product’s differentiators, further evolutions, potential optimizations (profit centers, cost centers…), team composition, etc.

  • Another concept that can support the engineering-business connection is Case Studies. Used mostly in the sales process to present engineering work in other projects to potential prospects, Case Studies tell a short condensed (no longer than a single-sided A4 piece of paper) story connecting business problems with technical challenges and solutions explaining the results and the impact on the business. But what if I say Case Studies can be useful not only in sales, and not only after the project is finished. As 2nd habit of “highly effective people” states, one should “begin with the end in mind”. Similarly, early efforts to think of the project end - the potential Case Study (the potential success story) of the project we are starting now - can encourage business and engineering to collaborate early and agree on how the success will look like before focusing on the details in both ends.

  • Is it me or testing community does not talk much about DDD? I explored some of my favorite sources (newsletters, blogs, archives) with little to no results. Google was not a great help as well as it was difficult to find anything with testing and DDD, but not TDD. However, I really liked one of the finds from Software Testing Weekly newsletter archives - “Applying Google’s Testing Methodology to Functional Domain-Driven Design For Scalable Testing” - as it gives some good advice in terms of test automation (applicable not only in the context of DDD). All in all, there is no obvious answer to the question - where do the test engineers plugin in the context of DDD? But it definitely is worth exploring.