There seems to be a gap in the market for tech books. What I want is something that’s got the plain-speaking “just do this, anything else is wrong” approach to code architecture of BM’s Clean Architecture, combined with the broad knowledge/systems architecture methods of DDD. What I want is something biblical, in the sense that it is definitive, and requires no thinking about other than whether to accept it whole or not.

Code and system architecture in an organisation where these things have not previously had a framework to drive them will be a hodge-podge of varying quality with little to no consistency, as a result of which decisions about the basics, and about who owns which parts of the scope, and even what “scope” is, need to be rehashed on every project. We end up with decisions in different places being made on the basis of who is involved, not according to any overarching plan, and lacking a framework to render some set of decisions pre-made, we relitigate the same problems over and over again, wasting time on irrelevancies instead of spending it on questions that could move us forward. We complain “there should be a plan for XYZ” when, with an appropriate framework in place, that plan would write itself.,

Domain-Driven Design is a particularly strong framework for dividing up an organisation’s activities. It doesn’t assume a greenfield, instead starting from where you are today and prescribing transformations for how to get to where you want to go. It provides a clearly-defined language for talking about software system construction: if you agree that you are doing DDD, then you agree on the definition of Bounded Context, Entity, Ubiquitous Language, and so on. It defines a Ubiquitous Language for the sorts of systems it teaches you how to build, in other words.

It is also well-contained in print publications which have a “biblical” status. Eric Evans' first book lays out the core, Implementing Domain Driven Design shows how to turn that into code, and Domain Driven Design Distilled gives a quick primer to get someone up to speed. Between those books, it is possible to say “if you’re not doing X, you’re doing it wrong.”

This is similar to another architectural approach, risk-based architecture (from Just Enough Architecture, by Fairbanks), where the you could equally say “yes, this is right” or “no, this is wrong” according to that approach, but the definitions are more woolly, more subject to interpretation, and provide less of a solid scaffold to build a team process around. For a team in a situation where there has historically been little in the way of coordinated architectural thinking, it does not supply the certainty, the just-do-this formula of DDD.

Where DDD ends and code organisation starts is where I see the gap. Clean Architecture dovetails nicely with DDD. As DDD supplies the domain boundaries and tells you which responsibilities lie with which software artefact and with which team, Clean Architecture tells that team how to implement the domain, and just as importantly how to organise the code around that domain so that the whole remains easy to change. And, just as with DDD, there is a print publication which has canonical status.

CA is not the only code architecture system existing in that part of the ecosystem. Hexagonal Architecture, and Ports And Adapters both look very similar, and could probably be employed by a team needing them with just the same success as CA. However, neither of them has what CA has, at least to my knowledge: a canonical reference to say “write your code this way”. Indeed, there are areas where the CA book itself leaves too much to interpretation: the later chapters would benefit massively from code examples to show the way. BM says that the architecture should “scream” but doesn’t really demonstrate what he means by that. The gaps are small enough that a motivated team would be able to fill them in, but I was disappointed that they existed at all.

Why not prescribe a combination of DDD and CA, then? Well, the main problem is that BM is a bin-fire of a human being. While his writing is persuasive, he has a tendency to treat approving reviews of his text as approving views of himself. He has a voice of authority which, to be perfectly clear, is good for absolute beginners who, at their level on the Dreyfus skill acquisition scale, do need to be told what to do without thinking too hard about it. This gains him followers who can be forgiven for not knowing any better, and who follow him well past the point that they benefit from his guidance. So, when thinly-disguised racism and misogyny rear their heads, the harm he does is magnified.

This militates strongly against recommending CA to an organisation containing (or hoping to contain) minorities: if use of the system can be taken as approval of the behaviour of the author, as we have reason to believe it would be by the author himself, no such use can morally be justified. This is additionally problematic when BM holds himself up as an arbiter of programmer ethics.

Compare this to Hexagonal Architecture. The author, designer, progenitor, source of the material Alastair Cockburn seems to take a far more flexible, discovery-led approach to team-level system design. This is unfortunate in the sense that it assumes a certain level of maturity in an organisation to be able to take on the message and run with it. Lacking the declamatory tone of CA means that the message is always subject to a certain amount of interpretation, to a far greater degree than CA. There is rarely a sense of “this is the right way”, more “this is a way which works for me”. That is a far more realistic and humane tone in the widest application, but for teams at the level where they need preaching at to get past the first on-ramp, it lacks punch, it lacks the crystal clarity of “there is one true way.” Over time, they may learn to relax the constraints but right here, right now, if they need certainty, HA doesn’t have the artifacts necessary to provide it.