11–20 of 133 posts
And when you try to prevent that IoC from leaking into the domain too much, the design often starts to look like hexagonal architecture.
Programming often feels like inventing a new form, but in the end we tend to converge on the shapes that previous programmers already discovered.
Most codebases eventually take on similar shapes, depending on their size and on the IoC model imposed by the framework. And when you try to prevent that IoC from leaking into the domain too much, the design often starts to look like hexagonal architecture. Programming often feels like inventing a new form, but in the end we tend to converge on the shapes that previous programmers already discovered.
Most codebases eventually take on similar shapes, depending on their size and on the IoC model imposed by the framework. And when you try to prevent that IoC from leaking into the domain too much, the design often starts to look like hexagonal architecture. Programming often feels like inventing a new form, but in the end we tend to converge on the shapes that previous programmers already discovered.
[flagged]
Most codebases eventually take on similar shapes, depending on their size and on the IoC model imposed by the framework. And when you try to prevent that IoC from leaking into the domain too much, the design often starts to look like hexagonal architecture. Programming often feels like inventing a new form, but in the end we tend to converge on the shapes that previous programmers already discovered.
Perhaps the real job of programmers is (or has been) adapting to new requirements. The art lies in the process, not in the result.
nevertheless, I often deceive myself into thinking that I am inventing a new design. In reality, I am usually just being shaped by the IoC model imposed by the framework and by the pressure of business requirements.
Only the scale changes. Similar problems tend to leave similar structures behind.
Sometimes it feels as if earlier generations of programmers have already solved so many of the important problems that all that remains for me is rediscovery.
But I do not want mere rediscovery. I want to create a new kind of problem. Still, in front of the solidity of established engineering, my small mind sometimes feels as if there is no place left for me.
Not all chapters are equally good or equally interesting, that's the curse of a multi-author book, and all of them are dated, but I think the book is worth reading nonetheless.
I think this really down plays the value of mental model or strategies for organizing code. Take a compiler: often described as a sequence of transformations on an AST, taken to the extreme in the nanopass framework. That's a really useful mental model, and you can extract that model and apply it in other contexts. For example, many business applications are a sequence of transformations on JSON. So they're basically…
I’m not sure what part of the article this is attempting to critique. But I would say that just because your preferred mental model is an abstract algebraic one where you build an abstract model that can apply to multiple situations doesn’t mean that such an architecture is best for every situation . The article talks very clearly about the system and social constraints that it is optimizing for architecturally and ‘…
I am trying to show 1) software architectures are useful, 2) if you abstract them you can find principles and relationships that allow you to transfer them to different domains, and transform them into different models, and 3) there is a lot of depth in software architecture and utility in learning it.
The article spends most of its time discussing social context in which architecture is developed (I agree it is important, but not everything) and in general downplays the utility of learning about software architecture (e.g. "“software design” is something best learned by doing", and later suggests there is little useful writing on software architecture).
I’m a NP - lots of learning came in clinical rotations where you see real life situations and how they are addressed. I want something like this for software architecture.
The closest I’ve seen is the open source case study books referenced previously but these are older.
I’d like to be able to see explanations at various layers of abstraction about why certain decisions are made or not.