How Much Architecture Is "Enough?"(infoq.com)
infoq.com
How Much Architecture Is "Enough?"
https://www.infoq.com/articles/mva-enough-architecture/
23 comments
Folks who enjoy this should consider reading Christopher Alexander's "The Nature of Order", which has some philosophy and metaphysics, but also a lot of analysis of concrete examples, of how complex structures come to be. It also attempts to analyze the process-oriented reasons behind guidelines like this.
I would also recommend 'Patterns of Software' by Richard Gabriel. In one of the chapters he discusses how Christopher Alexander's work can be applied to software and argues that GoF interpretation of 'pattern language' totally misses the point.
100%. If you read "A Pattern Language" and arrive at GoF, I'm not really sure how you got there.
That's called architecture. We don't need new terms to convince people they are doing something new so they feel better about reinventing the wheel and never making it round.
You'll know your architecture is complex enough when diagrams of it land you a big raise at a new company.
Until then you need more services.
Until then you need more services.
I was asked to review a multi-cloud architecture proposing to add several code repositories, multiple cross-cloud ETL pipelines, scalable big-data clusters, several and web and API apps -- with API management, of course! Some, but not all of that, was to be hosted on multiple Kubernetes clusters.
All of that for a project being implemented by one developer to generate one report.
My alternative solution was adding a single index and a PowerBI connector to the existing database.
They didn't like that and went with the original approach.
I didn't hear back.
All of that for a project being implemented by one developer to generate one report.
My alternative solution was adding a single index and a PowerBI connector to the existing database.
They didn't like that and went with the original approach.
I didn't hear back.
Don't forget that component/service names will need to be suitably enterprisified like so, for professionalism:
InterceptorWatcherCollectionClientDefinitionIteratorBroadcasterBasedObserver
I always use this tool when I feel that the stuff I'm churning out is substandard:
- https://projects.haykranen.nl/java/
InterceptorWatcherCollectionClientDefinitionIteratorBroadcasterBasedObserver
I always use this tool when I feel that the stuff I'm churning out is substandard:
- https://projects.haykranen.nl/java/
There is a class `ParameterizedAutoFactoryFactoryFactory`[1] in one of my pet projects.
The name does correctly reflect the purpose of this class. Although I could of course have come up with another one, the temptation of `Factory`x3 was just too strong to resist.
[1]: https://github.com/mykolav/unitycontainer-param-autofactory/...
The name does correctly reflect the purpose of this class. Although I could of course have come up with another one, the temptation of `Factory`x3 was just too strong to resist.
[1]: https://github.com/mykolav/unitycontainer-param-autofactory/...
That's even more inspired than RequestSpecificProcessorFactoryFactory from org.apache.xmlrpc.server:
https://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/serve...
https://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/serve...
ParameterizedAutoFactoryCubed
Power types: to multiply your effectiveness on those days when product and sum types just don't add up.
Here is a tutorial for correct naming: https://www.youtube.com/watch?v=y8OnoxKotPQ
Very informative. I only have one small gripe: I find that the 'Papaya' naming is somewhat unspecific, and somewhat ambiguous. I would have called it 'Wombat' for clarity, but overall I think these guys know what they're doing.
[deleted]
I've found that using techniques like C4 address this issue
hmm, not sure I understand how a particular approach to diagramming architecture even relates to things like determining the value of an MVP.
I found the linked article insightful, and the focus on making the MVA an explicit and crucial peer of a given MVP is, for me, a helpful framing of concerns that too often remain indistinct.
I found the linked article insightful, and the focus on making the MVA an explicit and crucial peer of a given MVP is, for me, a helpful framing of concerns that too often remain indistinct.
C4 pushes a broad view on the state of is and will be, with successive "zooming in" at different layers. The act of such allows you to figure out what's necessary and what's not, while also pushing the builders into thinking in terms of reusability/overlap/components/interfaces. Personal experience has proved that I wind up architecting for _less_ using this approach.
Thanks; that actually makes sense.
I find that asking do I really need this right now? Is generally good enough. Diagrams just help to see the lay of the land.
C4 is about diagramming software systems, and primarily existing ones at that. Not sure what this has to do with creating MVAs.
I think that is a joke about bombs.
I’ve been reading a lot of Kant recently and he has two ideas I think could be helpful to modern software engineering:
1. Using the word “architectonics” to describe the science of structures. Now it’s only used for the brain (Cytoarchitectonics) and some other small academic fields, sadly. I think that would be an awesome evolution for the slowly-outmoded agile coaches of the industry: “Architectonic consultants” or “architectonics”.
2. He thinks an important principle of Architectonics is not to just collect a bunch of components until you have a system that works, but rather to start with the top level, deduce the divisions within the structure that are necessary, and only then start filling in the details. In the practical world of engineering this isn’t always necessary, but I’ve found it really helpful, for the exact reasons discussed in this post (scoping, not getting ahead of yourself, allowing for growth without doing unnecessarily early work, etc)