12 ms·
> Software architecture is fundamentally about understanding the shape and structure of the problem domain, understanding the capabilities of your engineering t
by vvanders 6y ago
> Software architecture is fundamentally about understanding the shape and structure of the problem domain, understanding the capabilities of your engineering tools, and creating an architecture where both domains support each other. Your overall system architecture should flex where the problem domain flexes, and may be rigid where the problem doman is rigid. (It really does "depend on your use-case".)
Can I just say that I really like this framing, I think it succinctly captures why you see such a broad range in languages/frameworks and why there hasn't been one software solution that fits most problems.
- Geminidog 6y agoIt captured nothing in my view. Even a formal solution won't necessarily have a single solution for all problems. Likely there are several optimal solutions given for each problem that exists. What formality will tell us is whether or not that solution is definitively optimal. Right now our definition of an "optimal design" is whoever wins the "design argument" flame war.
- TeMPOraL 6y agoExcept the framing is bad, in my experience. For any non-trivial software, the architecture quickly becomes 10% about problem domain, and 90% about internal code bureaucracy. The latter is something that's to a large extent problem-independent, and yet we're still spinning in circles about it for some reason. (By internal code bureaucracy I mean the art of structuring and connecting all the abstractions in your code, the coding of pathways the data travels and transformations it undergoes, etc. Ever had a situation where a seemingly simple feature required you to touch half of your system, as you routed and transformed a piece of information from a place that produced it to the place that consumed it? That's code bureaucracy.)