Prologue Comments

[iancooper]

— I’m not sure that software is inherently unstable without energy. If I applied no energy, in other words did not work on it, it might become out-of-date, un-patched and decay but not become chaotic. A big-ball of mud occurs because we trade-off the modifiability of the software against another requirement such as time-to-market or performance. We might have valid reasons to make that trade-off, but we incur a modifiability debt as a result.

— You can explain DI more easily once you have introduced layers by noting that as we depend downwards, it becomes impossible to use something from a higher layer. To correct this, you need to create an interface in your layer, and have something in the higher layer implement that. The DI is when you provide the concrete dependency when calling the lower layer. Hexagonal architectures with their ‘depend inwards’ model are even clearer here, because for the port layer to do I/O it must depend on the adapter layer above it, which it can’t do, so it creates a DAO abstraction, depends on that, and has that implemented in the adapter layer.

Domain Modelling
DDD did not originate domain modelling. It itself calls out Object Design from Rebecca Whirfs-Brock and Alan McKean, which introduced Responsibility Driven Design of which DDD is a special case, dealing with the domain. That is the book with CRC cards, object stereotypes etc. But even that is too late and you need to call out Ivar Jacobson and Grady Booch. The term has been around since the mid-1980s. The big change was perhaps that Jacobson and Whirfs-Brock called out using UML to model something other than the domain. DDD’s main ‘addition’ to our knowledge was ubiquitous language and bounded context.

[bobthemighty]

I’m not sure that software is inherently unstable without energy.

That's fair. The idea I'm grasping toward, I guess, is that the maintainability of a piece of software naturally trends downward as the complexity increases. It takes directed energy to prevent that by continuously refactoring and moving further up the abstraction ladder.

[iancooper]

Right, trying to wrack my brain for a better metaphor for something that decays without oversight as it grows.

[hjwp]

gardening?

[bobthemighty]

I often think about bonsai as a metaphor for programming. Gardening definitely works, I think.

…

On Mon, Jul 1, 2019 at 3:55 PM Harry Percival ***@***.***> wrote: gardening? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#49>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAMNTPSFWEVS5WKXN4JAL3P5ILH5ANCNFSM4H4HGLXQ> .

-- Q. How many members of a demographic group does it take to perform a specified task? A. A finite number; one to perform the task, and the remainder to act in a manner stereotypical of the group in question.

[hjwp]

ok have addressed points 1 and 3. just need to figure out a way to express this:

You can explain DI more easily once you have introduced layers by noting that as we depend downwards, it becomes impossible to use something from a higher layer.

[xtaje]

Re: metaphors, one of our engineers likes to use the term "code gardening" for tech debt, so that's a fine idea. I'm just throwing a few more ideas out to spark some lateral thinking, and since Harry was tweeting about "Cosmic Python".

WRT "energy" and "stability" (if you were still going to use that metaphor) arguably energy or entropy also comes in the form of changing requirements, new feature requests, new technologies, changes to the team, etc.

Some other pattern nicknames/metaphors from the original BBOM piece include "Shantytown", "Potemkin Viliage", "Urban Sprawl", trench warfare.

For DI, perhaps you could put the very first part of the filesystem example in the prologue? It would create kind of a cliffhanger and a concrete example to motivate DI. Then in the following chapters, do the refactors to FCIS and DI.

On a 'Buzzword': Hierarchical Structure is very old, but I think relevant to the discussion around layers. It may be helpful.