Hello!
I'm Jairo Jr, your favorite Dev.to writter, or something like this 😄.
Over the last few years, I've spent a lot of time studying software architecture. Like most backend engineers, I've gone through the usual journey: Layered Architecture, Clean Architecture, Hexagonal Architecture, Event-Driven Architecture, and Microservices.
While exploring different concepts, I found an architecture style that immediately caught my attention: Library Oriented Architecture (LOA).
I first discovered the term while reading an article by Krystian Kościelniak, and it completely changed how I think about domains and code organization.
The funny thing is that the idea sounds almost too simple.
And if you're a software engineer, you already know that's usually when things get dangerous 😄.
🤔 The Problem Every Growing Application Faces
Have you ever opened a codebase and asked yourself:
Where does one domain end and another begin?
At first, everything seems organized. Then the project grows, new features arrive, more business rules appear, and suddenly billing knows about users, users know about notifications, notifications know about payments, and nobody knows who owns what anymore.
The code still works, but the boundaries become blurry. And blurry boundaries usually create expensive problems.
The problem looks something like this:
Once you start thinking about systems as collections of concepts and relationships, LOA begins to make a lot more sense.
📚 The Core Idea Behind LOA
The central idea of Library Oriented Architecture is surprisingly simple:
Each domain becomes a library.
That's it.
No secret framework.
No new runtime.
No AI-powered blockchain-driven microservice mesh 🚀✨😅.
Not a package.
Not a folder.
Not a module hidden inside a monolith.
A real library.
Each library contains everything related to that specific business capability:
- Domain concepts
- Domain rules
- Domain behavior
- Domain use cases
For example:
customer-library
payment-library
inventory-library
notification-library
Each one owns its knowledge.
Each one owns its rules.
Each one owns its evolution.
Instead of having a giant application where domains are mixed together, you have independent units with explicit ownership.
The architecture can be divided into three major parts: the Application, the Middleware, and the Domain Libraries.
Application
The application is the entry point of the system.
It contains framework integrations, dependency injection, controllers, API endpoints, and infrastructure configuration.
Its responsibility is orchestration.
The application knows how to connect things together, but it does not own domain knowledge.
Middleware
The middleware acts as a bridge between the application and the libraries.
Its responsibility is providing common services such as:
- HTTP communication
- Caching
- Persistence abstractions
- Messaging
- Shared utilities
The goal is avoiding direct infrastructure coupling inside domain libraries.
Libraries
This is where the business actually lives.
Each library contains:
- Business entities
- Business rules
- Use cases
- Domain logic
Ideally, it contains no framework dependencies, no infrastructure concerns, and no knowledge about the application itself.
The library only knows its domain.
And that's powerful.
Another way to visualize it is:
🤖 The Unexpected Advantage of LOA in the AI Era
One thing I realized while studying LOA is how naturally it fits the world of AI agents.
Which was unexpected. I started reading about architecture and somehow ended up thinking about context windows and token consumption 🤖.
One of the biggest challenges when building AI-powered systems is context management. The more information you provide to an agent, the more expensive, slower, and sometimes less accurate the responses become.
With LOA, domain boundaries naturally become context boundaries.
Instead of giving an agent access to the entire application, you can provide only the library related to the problem being solved.
A Payment Agent only needs payment concepts. An Inventory Agent only needs inventory concepts.
The result is lower token consumption, more focused reasoning, and agents that behave much closer to specialists than generalists.
As AI becomes part of software architecture, this may become one of the most interesting benefits of LOA.
✅ Advantages
After studying the concept, these are the biggest benefits I see.
Clear Domain Boundaries
Every domain has an explicit home. This makes ownership easier to understand and reduces the chances of business rules leaking into unrelated parts of the system.
High Reusability
Because domains are packaged as libraries, they can be reused across multiple applications without bringing the entire codebase with them.
Easier Testing
Domain logic becomes easier to isolate, making unit and integration tests simpler to write and maintain.
Framework Independence
Business rules remain independent from Spring, Express, ASP.NET, or any other framework, reducing long-term coupling.
Better Long-Term Maintainability
Clear boundaries and reduced coupling make the system easier to evolve as business requirements grow.
⚠️ Potential Drawbacks
Of course, no architecture is perfect.
LOA also introduces challenges.
More Initial Design Effort
LOA requires careful thinking about domain boundaries. Poor boundaries can create as many problems as no boundaries at all.
Package Management Complexity
As the number of domains grows, managing versions and dependencies between libraries becomes more challenging.
Not Ideal for Every Project
Smaller applications may not benefit enough from the additional structure to justify the added complexity.
Like most architectural decisions, LOA is a trade-off, not a silver bullet.
🚀 Final Thoughts
What I like most about Library Oriented Architecture isn't the libraries themselves.
It's the mindset.
LOA forces us to think about domains as first-class citizens—not folders, not modules, and not technical layers.
Domains.
Will LOA replace Hexagonal Architecture, Clean Architecture, or Modular Monoliths?
Probably not.
But it offers an interesting perspective:
What if the domain wasn't a part of the application?
What if the application was simply orchestrating a collection of domains?
And that's a question I've been thinking about ever since I discovered this architecture style.
Maybe LOA won't become the next big architecture trend.
But it definitely made me look at domains differently—and for me, that's already a win 🎯.
SOCIAL SHARE CARD GENERATOR