Lesson 155 - Infinity Architecture AntiPattern
HTML-код
- Опубликовано: 10 сен 2024
- The infinity architecture anti-pattern can take on many forms. In this lesson I define what the infinity architecture anti-pattern is and show some real-world examples of this all-to-common anti-pattern, and also ways to avoid it. Then I show another form of this anti-pattern involving contracts between services or components.
Reference Links:
Software Architecture Monday: bit.ly/3dadEe3
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2
We already have a few of these "everything architectures" - Java, Python, Go...
Designing an architecture to fit all systems is like architecting a building to fit all uses, and it's obvious that even if the building blocks are nearly identical, the design for a school won't be great for an apartment building or a shopping mall
Interesting, because that was the original intent of the IBM San Francisco project - create general, reusable business components as "building blocks"; it didn't work because even the building blocks of an architecture can't be made generic.
Thanks for sharing! 👍
Thank you!
Mark wrote for '97 Things Every Software Architect Should Know.' Kevlin Henney mentioned this antipattern by another name: Specificity Before Generality, Use Before Reuse.
Indeed another great source for this antipattern
On the same line of thoughts, if we can't have an infinity general software architecture, does it mean we can't have general purpose AI either?
Interesting parallel. I think we can have a general purpose AI, with the conversation providing the context.
I don't see a parallel
General AI is usually considered something that simulates a human. If we have one AI that simulates conversation and another that simulates art generation and another that simulates mathematical thinking and another that handles audio processing and another that handles physical movement, and maybe there's one orchestrating AI that continually trains the other pieces as it sees fit, or maybe even creates new specialized AIs on new input sources (e.g connect a forklift, see it learn how to handle it in a few minutes of trial and error), we get something that we would probably consider general AI just from a bunch of specialized AIs
To parallel with architectures, you can have an architecture that "kinda works" for everything, e.g. the good old monolith, and it would be the parallel of a general AI that "kinda does human stuff"
Also, we should remember that architectures are mostly created to help humans handle complexity, they're not the goal, they're the tool. A superintelligence building a software system wouldn't need any organization method, it could just slap everything in one giant set of files with arbitrary code blocks and still be able to understand and adapt it - it doesn't care about elegance or duplication or coupling, anything goes if it hits the target
What if we use some "exotic" form of map for the contract that can validate and provide some details about it? ;)
Sort of like consumer-driven contracts in a way?
@@markrichards5014 Yes, sort of, if I uderstand the reason for having customer-driven contracts correctly: we could have a shared repository of schemas where both providers and consumers coexist, I could think of some way of writing an integration tests for them... then the schemas could evolve dynamically by altering their fields. So the input schema for the service would be a bit more "intelligent" hash-map with capabilities of pre-validating the input and so on ...
The only question after this, is how to provide this concept to business people…
Great question. Help them articulate what sort of characteristics are truly critical to the success of the system. Is it scalability? Performance? Agility? This helps narrow the scope of the architecture. Another suggestion is to demonstrate the cost and time involved in creating things that "might be needed in the future".