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:
As applications grow, ownership becomes harder to understand. A feature that originally belonged to one domain slowly starts leaking into others, creating dependencies that nobody planned and everyone eventually has to maintain.
๐ง Before LOA, We Need to Talk About Ontologies
To understand Library Oriented Architecture, we first need to understand a concept called Ontology.
The word ontology sounds much more complicated than it actually is.
Honestly, the first time I read the word, I thought I was accidentally reading a philosophy book instead of a software architecture article ๐.
In software terms, an ontology is simply a way to describe concepts, relationships, and business rules inside a specific domain.
Think about an e-commerce platform. You have Customers, Orders, Products, and Payments. More importantly, you have rules that connect those concepts together.
For example:
- Customers create Orders
- Orders contain Products
- Payments settle Orders
An ontology defines that language and those relationships. In other words:
An ontology describes the language of a domain.
Visually, it 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 domain stops being a section of the application and becomes a first-class citizen.
๐๏ธ The Structure
A simplified LOA application usually looks like this:
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:
๐ก Why I Like This Idea
The biggest thing that attracted me to LOA is clarity.
When a domain becomes a library, ownership becomes explicit. You immediately know where business rules belong, where changes should happen, and who owns a particular piece of functionality.
After working with large codebases for years, I've noticed that many architecture problems aren't technical problems at all.
They're ownership problems.
LOA addresses that challenge directly by making domain boundaries visible and enforceable.
The architecture encourages engineers to think in terms of business capabilities instead of technical layers, which tends to produce cleaner and more maintainable systems over time.
๐ Isn't This Just a Modular Monolith?
At first glance, it looks very similar.
And honestly, there is some overlap.
If you're thinking:
This sounds suspiciously like a modular monolith.
You're not alone.
I had exactly the same reaction ๐ .
Both approaches aim to create strong boundaries and reduce coupling.
The difference is that LOA pushes modularity one step further.
Instead of thinking:
This folder belongs to the payment module.
You start thinking:
This library IS the payment domain.
That subtle difference changes how teams design software.
The domain stops being a folder inside the application and becomes an independent unit with its own lifecycle and ownership.
๐ค 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 ๐ฏ.
