Katharina Damschen

This post appeared first on factor10.com. It just doesn’t make any sense! Your software team has been getting slower and slower up to a point where every new feature is painfully forced through the system, wrecking everything it touches, leaving everyone afraid to make any changes in the first place and adding more and more defensive processes that slow the system down additionally.

In the blogpost about structural idealization I explained how structural engineers model reality to answer the question whether their designed structure can withstand the forces applied to it. But how does an engineer know which forces will be applied to their structure? The weight of the structure can be approximated at best, and natural occurrences like wind or snow or a car crashing into the building are much harder to anticipate and quantify. And how does an engineer consider a car crashing into the structure while still building reasonably economical?

I sometimes joke that I have gone full-circle: from Structural Engineer to Software Architect. Structural Engineering and Architecture are of course not at all the same thing (like you can never suggest that to either Structural Engineers or Architects!), but people tend to mix those two up. I in fact think it should be called ‘Software Structural Engineer’ instead of Software Architect. That would be more correct and would make my joke funnier. Let me explain…

I started my software development career as a structural engineer who programmed, developing analytical applications for other engineers. When I moved to a traditional software company, I went from one extreme to another, from having all the roles of a software development team at once to becoming a “code monkey” with no context about what I was building and why. In search of a middle ground I came across Domain-Driven Design (DDD), which in its essence is about getting to know the Domain you are developing software for. But without being a Domain expert yourself.

About a year ago I attended a workshop held by Dan Bergh Johnsson and Daniel Deogun, authors of the book Secure By Design. They presented the topics of their book and on three additional occasions we met in smaller groups and had guided discussions on the topics. I like the mix of Domain Driven Design and cybersecurity a lot, it gave me a whole new perspective (and justification!) on why to apply Domain Driven Design. One concept I have been using extensively since I read the book is Domain Primitives and I want to share how I utilize it.