1. 15
  1. 12

    While I find the writing of Martin Fowler to be good for getting ideas on new patterns or existing ones, better expressed, I strongly disagree calling this page a software architecture guide. Software architecture is a lot more than these patterns and approaches.

    I’ve been building a few large distributed systems and been in the design loop of many more the past few years, within Uber. Software design/architecture of these systems resembled anything but what the articles talk about.

    We did not use patterns or find the best architecture matches. Instead, we looked at the business case, the problem and the constraints. We whiteboarded, argued and discussed approaches, trade offs and short-medium-long-term impacts. We prototyped, took learnings, documented the whiteboard approach that made sense, then circulated the proposal. We debated some more over comments and in-person, then built an MVP, shipped it and went on with the same approach to the next phase, all the way to migrating over to the new system.

    Nowhere in this process did we talk the kind of patterns this post talks about. We talked tradeoffs and clashed ideas all the time though.

    Talking with friends in the industry, the same applies for much of the large systems built by tech companies across Uber, Amazon, Facebook, Google. If you read the design documents, they use little to no jargon, simple diagrams, little to no reference to patterns and are full of back-and-forth comments.

    Maybe I live and work in a different environment than Martin Fowler. But where his thoughts of architecture end is where my world just about begins.

    Also, as my view is so different on this topic than this post, I’ll likely write up my thoughts/experience in a longer form.

    1. 6

      I agree, what you describe is the way to go. You start with the business case, you think it through collaboratively, and you figure out the best plan you can for (a) getting it done, so that (b) you can maintain it with velocity from then on.

      But I don’t think Fowler advocates anything against that.

      I think, if you and some teammates were doing that, and Fowler was around, he’d be listening, understanding, and identifying patterns that he could document. Then he’d be remarkably good at explaining them to management and to the Product team. He also might overhear a conversation and say, “We struggled with that at xyz. Here’s what we did.” And he might even point to one of his own articles in that case.

      I think what often goes wrong is developers often start with a blank whiteboard, panic, and then grab Fowler’s or some other author’s works, and try to make them fit.

      Rather, the process should be: start with a blank whiteboard, think hard, sketch out some ideas and identify challenges, then maybe see if any documented patterns or ideas might help.

      1. 3

        Do you ever retroactively try to identify what architectural patterns you ended up with, for instance to mention in documentation? In the end I would say patterns are mainly useful as a convenient shorthand to communicate parts of the design, more than a toolbox to try and apply.

      2. 5

        Maybe I live and work in a different environment than Martin Fowler.

        This touches on something I’ve been thinking about for quite a while. That there are broad categories of sofware application, and that programmers typically have a perspective only on those they have actually experienced. I’m not talking here in your case, but more generally.

        For many new in the industry, there is a perspective that software is limited to problems in the computer and data sciences, and those involving computing infrastructure. Often these undertakings have a focus largely on what may be considered non-functional requirements, where functional requirements (and how to represent them in code) is of relatively little importance. Issues such as how to scale, be reliable, available, accessible and so forth are paramount.

        On the other hand, there are a large proportion of applications where how to model a complex problem domain into code is the issue. Typically a problem domain where expertise is outside of the development team. How to discover, manage and implement functional requirements into code is the core issue. It is this later world that Martin Fowler primarily lives in and writes about.

        Is such a categorization of any value?

        1. 2

          Possibly, but the example you give sounds to me like it intermingles the datamodel / domain structure / domain architecture with the software architecture, while the former, in my view, is mostly one of many constraints on the latter and one that can be used to ‘encode/compress’ part of the functional requirements. However, you can’t design a good software architecture without taking all functional requirements into account, while at the same time you also need to take all other requirements into account: after all, there is only one software architecture.

          1. 1

            I think this is a good categorization.

        2. 1

          I think that software architecture is an increasingly important field. The approach from the 90s showed its limits (ie. applying the metaphor of building construction to software), but given that creating programs has shifted from a handful of relatively independent, experienced hackers to an army of bootcamp-trained developers, the role of architecture is going to be more and more prominent. The key challenge is the same: how do we approach the design of a computer program, taking into account not only what it should do, but how it’s going to be made.