Library Oriented Architecture: The Most Interesting Architecture Pattern You've Probably Never Heard About

Source: Dev.to

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 😄. 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. 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 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. 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. 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. 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. 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 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. 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.

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. After studying the concept, these are the biggest benefits I see. 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. Because domains are packaged as libraries, they can be reused across multiple applications without bringing the entire codebase with them. Domain logic becomes easier to isolate, making unit and integration tests simpler to write and maintain. Business rules remain independent from Spring, Express, ASP.NET, or any other framework, reducing long-term coupling. Clear boundaries and reduced coupling make the system easier to evolve as business requirements grow. Of course, no architecture is perfect. LOA also introduces challenges. LOA requires careful thinking about domain boundaries. Poor boundaries can create as many problems as no boundaries at all. As the number of domains grows, managing versions and dependencies between libraries becomes more challenging. 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. 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 🎯.