Stolen from Wikipedia
A set of principles and methodologies for designing and developing software in the form of reusable libraries under a specific ontology domain.
Dictates the boundaries of a library that exposes business functionality through a set of public APIs. Encourages the maintenance of internal libraries and modules with independent internal life-cycles.
Promotes Modular Programming, Separation of Conterns and designing to interfaces instead to implementations.
Key principles
- A library responsibility must be constrained to only one ontology domain.
- A library that needs to use concepts/artifacts from a different ontology domain than the one it belongs to, must interface and reuse the library corresponding to that specific ontology domain.
- All domain specific libraries must be maintained and supported with separate life-cycles.
Benefits
While the above may seem constraining, adopting the Library Oriented Architecture gives you several benefits:
- Simplicity of configuration management
- Improvement of the system reliability
- Independence of technology
- It's easy to replace a library implementation with another one without affecting the library consumer (as long as the API is the same)
- Increase of the development speed
- The development team doesn't have to know everything about the system. They just need to know the responsibilities of and the requirements for the library they are developing
- Debugging is also easier
- Increment of the bus-factor
- The less complex system, the higher bus factor is 🤷♂️
- Minimized risk of [high coupling](https://en.wikipedia.org/wiki/Coupling_(computer_programming)
- especially in big, distributed systems