Software architecture provides boundaries for TDD, BDD, DDD, RDD and clean code

One of the recurring questions I get asked whenever I talk to teams about software architecture is how it relates to techniques such as TDD, BDD, DDD, RDD, etc. The question really relates to whether xDD is a substitute for "software architecture". The short answer is no. The slightly longer answer is that the process of thinking about software architecture is really about putting some boundaries in place, inside which you can build your software using whatever xDD practices/principles you like.

For me, the "why?" is simple - you need to think about the things that play a huge part in influencing the resulting software architecture that you come up with, including:

  • Functional requirements: As Tom Gilb says in pretty much all of his software architecture talks, requirements drive architecture. You need to know vaguely what you're building, irrespective of how you capture and record those requirements (i.e. user stories, use cases, requirements specifications, acceptance tests, etc).
  • Quality attributes: The non-functional requirements (e.g. performance, scalability, security, etc) are usually technical in nature and are hard to retrofit. They ideally need to be baked into the initial design and ignoring these qualities will lead you to a software system that is either over- or under-engineered.
  • Constraints: The real-world usually has constraints; ranging from approved technology lists, prescribed integration standards, target deployment environment, size of team, etc. Again, not considering these could cause you to deliver a software system that doesn't complement your environment, adding unnecessary friction.
  • Principles: These are the things that you want to adopt in an attempt to provide consistency and clarity to the software. From a design perspective, this includes things like your decomposition strategy (e.g. layers vs components vs micro-services), separation of concerns, architectural patterns, etc. Explicitly outlining a starting set of principles is essential so that the team building the software starts out heading in the same direction.

Considering these important elements needn't take very long and can provide you with a starting point for the rest of the software design activities. Of course, this doesn't mean that the architecture shouldn't be changed, especially when you start writing code and getting feedback. The point is that you now have a framework and some boundaries to work within, which provide some often needed vision and guidance for the team. My experience suggests that a little direction can go a long way.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.




Add a comment Send a TrackBack