45:"/_next/static/chunks/33yus346z0l_n.js" 46:"/_next/static/chunks/2j22cxchii_xx.js" 47:"/_next/static/chunks/0iv56yrji_20j.js" 48:"/_next/static/chunks/32izpn90gvm22.js" 49:"/_next/static/chunks/3j8bi-zu9bqs4.js" 4a:"/_next/static/chunks/1z-pox7hqp2x3.js" 4b:"/_next/static/chunks/20w4eaqlekefm.js" 4c:"/_next/static/chunks/1tn-0fivsxsv1.js" 4d:"/_next/static/chunks/09nq57stwzkgf.js" 4e:"/_next/static/chunks/3m1xjj5kw5fie.js" 4f:"/_next/static/chunks/0gafyzg9j9yqj.js" 50:"/_next/static/chunks/3k2gyg36fnag_.js" 51:"/_next/static/chunks/3bgoyiso1rhn7.js" 52:"/_next/static/chunks/3cstd6xzfli_o.js" 53:"/_next/static/chunks/253gnmj0-cj17.js" 54:"/_next/static/chunks/0hlb44ca7-4a2.js" 55:"/_next/static/chunks/20329i6m_04t6.js" 56:"/_next/static/chunks/40mq7ggq-ozo4.js" 57:"/_next/static/chunks/082jo-0ajazgr.js" 58:"/_next/static/chunks/2ozcrjb_hh74t.js" 59:"/_next/static/chunks/01a-3hvnqu8wl.js" 5a:"/_next/static/chunks/05i8en-x14ibi.js" 5b:"/_next/static/chunks/3m0r7x0jt5wm7.js" 5c:"/_next/static/chunks/2k8pepwc4pxns.js" 5d:"/_next/static/chunks/0wa9m1-tphf9u.js" 5e:"/_next/static/chunks/30jdm3dwz834g.js" 5f:"/_next/static/chunks/0k9bl6dipnsvu.js" 60:"/_next/static/chunks/18ggtgz2yf759.js" 61:"/_next/static/chunks/0i3-eynrkvqi7.js" 62:I[593304,["$2a","$2b","$2c","$2d","$2e","$2f","$45","$46","$47","$48","$49","$4a","$4b","$4c","$4d","$4e","$4f","$50","$51","$52","$53","$54","$55","$56","$57","$58","$59","$5a","$5b","$5c","$5d","$5e","$5f","$60","$61"],"OwnedHydration"] 63:T7ad,Onion Architecture addresses these problems through a fundamental insight: **dependencies should flow toward the center, not toward the edges**. Instead of your business logic depending on your database, your database adapters should depend on interfaces defined by your business logic. The direction of dependencies is inverted: ``` Traditional Onion ┌─────────────┐ ┌─────────────────┐ │ UI │ │ Infrastructure │ └──────┬──────┘ │ (Outer) │ │ depends on └────────┬────────┘ ▼ │ depends on ┌─────────────┐ ▼ │ Business │ ┌─────────────────┐ └──────┬──────┘ │ Application │ │ depends on │ Services │ ▼ └────────┬────────┘ ┌─────────────┐ │ depends on │ Database │ ▼ └─────────────┘ ┌─────────────────┐ │ Domain Model │ │ (Center) │ └─────────────────┘ ``` This inversion is the key to everything else in Onion Architecture. By making dependencies flow inward, we create a protective barrier around our domain logic.64:T9fd,The name 'Onion Architecture' comes from its characteristic visualization: concentric circles, each representing a layer of abstraction, with the domain at the center and infrastructure at the outermost edge: ``` ┌────────────────────────────────────────────────┐ │ INFRASTRUCTURE LAYER │ │ (Web Controllers, Databases, Messaging, │ │ File Systems, External APIs, IoC Container) │ │ ┌──────────────────────────────────────────┐ │ │ │ APPLICATION SERVICES │ │ │ │ (Use Cases, Orchestration Logic, │ │ │ │ Application-specific Business Rules) │ │ │ │ ┌──────────────────────────────────────┐│ │ │ │ │ DOMAIN SERVICES ││ │ │ │ │ (Domain Operations that don't belong ││ │ │ │ │ to a single Entity or Value Object) ││ │ │ │ │ ┌──────────────────────────────────┐││ │ │ │ │ │ DOMAIN MODEL │││ │ │ │ │ │ (Entities, Value Objects, │││ │ │ │ │ │ Aggregates, Domain Events) │││ │ │ │ │ └──────────────────────────────────┘││ │ │ │ └──────────────────────────────────────┘│ │ │ └──────────────────────────────────────────┘ │ └────────────────────────────────────────────────┘ ``` **Each layer encapsulates a different level of abstraction:**65:T712,// Domain Model - No dependencies on infrastructure // Value Object: Immutable, equality by value class Money { private constructor( private readonly amount: number, private readonly currency: string ) { if (amount < 0) throw new Error("Amount cannot be negative"); if (!["USD", "EUR", "GBP"].includes(currency)) { throw new Error(`Invalid currency: ${currency}`); } } static of(amount: number, currency: string): Money { return new Money(amount, currency); } add(other: Money): Money { if (this.currency !== other.currency) { throw new Error("Cannot add different currencies"); } return new Money(this.amount + other.amount, this.currency); } equals(other: Money): boolean { return this.amount === other.amount && this.currency === other.currency; } } // Entity: Identity-based, mutable (through controlled operations) class Account { private balance: Money; constructor( readonly id: AccountId, private readonly owner: CustomerId, initialBalance: Money ) { this.balance = initialBalance; } deposit(amount: Money): void { this.balance = this.balance.add(amount); } withdraw(amount: Money): void { const newBalance = this.balance.subtract(amount); if (newBalance.isNegative()) { throw new InsufficientFundsError(this.id, amount); } this.balance = newBalance; } getBalance(): Money { return this.balance; } } // Repository Interface - Defined in domain, implemented in infrastructure interface IAccountRepository { findById(id: AccountId): Promise; save(account: Account): Promise; }66:T8eb,// Domain Model - No dependencies on infrastructure // Value Object: Immutable, equality by value public final class Money { private final BigDecimal amount; private final Currency currency; private Money(BigDecimal amount, Currency currency) { if (amount.compareTo(BigDecimal.ZERO) < 0) { throw new IllegalArgumentException("Amount cannot be negative"); } this.amount = amount; this.currency = Objects.requireNonNull(currency); } public static Money of(BigDecimal amount, Currency currency) { return new Money(amount, currency); } public Money add(Money other) { if (!this.currency.equals(other.currency)) { throw new CurrencyMismatchException(this.currency, other.currency); } return new Money(this.amount.add(other.amount), this.currency); } @Override public boolean equals(Object o) { if (this == o) return true; if (!(o instanceof Money)) return false; Money money = (Money) o; return amount.equals(money.amount) && currency.equals(money.currency); } @Override public int hashCode() { return Objects.hash(amount, currency); } } // Entity: Identity-based, mutable (through controlled operations) public class Account { private final AccountId id; private final CustomerId owner; private Money balance; public Account(AccountId id, CustomerId owner, Money initialBalance) { this.id = Objects.requireNonNull(id); this.owner = Objects.requireNonNull(owner); this.balance = Objects.requireNonNull(initialBalance); } public void deposit(Money amount) { this.balance = this.balance.add(amount); } public void withdraw(Money amount) { Money newBalance = this.balance.subtract(amount); if (newBalance.isNegative()) { throw new InsufficientFundsException(this.id, amount); } this.balance = newBalance; } public Money getBalance() { return this.balance; } } // Repository Interface - Defined in domain, implemented in infrastructure public interface AccountRepository { Optional findById(AccountId id); void save(Account account); }67:T818,// Infrastructure - Implements interfaces defined in domain // Repository implementation using PostgreSQL class PostgresAccountRepository implements IAccountRepository { constructor(private readonly db: DatabaseConnection) {} async findById(id: AccountId): Promise { const row = await this.db.query( `SELECT id, owner_id, balance, currency FROM accounts WHERE id = $1`, [id.value] ); if (!row) return null; // Transform database row to domain entity return new Account( new AccountId(row.id), new CustomerId(row.owner_id), Money.of(row.balance, row.currency) ); } async save(account: Account): Promise { await this.db.query( `INSERT INTO accounts (id, owner_id, balance, currency) VALUES ($1, $2, $3, $4) ON CONFLICT (id) DO UPDATE SET balance = EXCLUDED.balance`, [ account.id.value, account.owner.value, account.getBalance().amount, account.getBalance().currency ] ); } } // Web Controller in infrastructure layer class AccountController { constructor( private readonly transferService: TransferFundsService ) {} async handleTransfer(req: Request): Promise { // Parse HTTP-specific concerns const { fromAccountId, toAccountId, amount, currency } = req.body; try { // Call application service await this.transferService.execute( new AccountId(fromAccountId), new AccountId(toAccountId), Money.of(parseFloat(amount), currency) ); return { status: 200, body: { success: true } }; } catch (error) { if (error instanceof InsufficientFundsError) { return { status: 400, body: { error: error.message } }; } throw error; } } }68:T885,// Infrastructure - Implements interfaces defined in domain // Repository implementation using JPA @Repository public class JpaAccountRepository implements AccountRepository { private final EntityManager entityManager; public JpaAccountRepository(EntityManager entityManager) { this.entityManager = entityManager; } @Override public Optional findById(AccountId id) { AccountJpaEntity entity = entityManager.find( AccountJpaEntity.class, id.getValue() ); if (entity == null) return Optional.empty(); // Transform JPA entity to domain entity return Optional.of(new Account( new AccountId(entity.getId()), new CustomerId(entity.getOwnerId()), Money.of(entity.getBalance(), entity.getCurrency()) )); } @Override public void save(Account account) { AccountJpaEntity entity = new AccountJpaEntity(); entity.setId(account.getId().getValue()); entity.setOwnerId(account.getOwner().getValue()); entity.setBalance(account.getBalance().getAmount()); entity.setCurrency(account.getBalance().getCurrency().toString()); entityManager.merge(entity); } } // Web Controller in infrastructure layer @RestController @RequestMapping("/api/transfers") public class AccountController { private final TransferFundsService transferService; public AccountController(TransferFundsService transferService) { this.transferService = transferService; } @PostMapping public ResponseEntity handleTransfer(@RequestBody TransferRequest request) { try { transferService.execute( new AccountId(request.getFromAccountId()), new AccountId(request.getToAccountId()), Money.of(request.getAmount(), request.getCurrency()) ); return ResponseEntity.ok(new SuccessResponse()); } catch (InsufficientFundsException e) { return ResponseEntity.badRequest() .body(new ErrorResponse(e.getMessage())); } } }69:Tafc,// =============================================== // DOMAIN LAYER - Defines interfaces (contracts) // =============================================== // These interfaces express what the domain NEEDS // They don't say HOW those needs are met interface IAccountRepository { findById(id: AccountId): Promise; save(account: Account): Promise; findByCustomer(customerId: CustomerId): Promise; } interface INotificationService { notifyOverdraft(account: Account, attemptedAmount: Money): Promise; notifyLargeTransaction(account: Account, amount: Money): Promise; } interface IAuditLogger { logTransfer(from: Account, to: Account, amount: Money): void; logFailedTransfer(from: AccountId, to: AccountId, reason: string): void; } // =============================================== // APPLICATION LAYER - Uses interfaces // =============================================== class TransferFundsService { constructor( private readonly accountRepo: IAccountRepository, private readonly notifications: INotificationService, private readonly audit: IAuditLogger ) {} async execute( fromId: AccountId, toId: AccountId, amount: Money ): Promise { const fromAccount = await this.accountRepo.findById(fromId); const toAccount = await this.accountRepo.findById(toId); // Domain validation if (!fromAccount || !toAccount) { throw new AccountNotFoundError(); } try { fromAccount.withdraw(amount); toAccount.deposit(amount); // Persist changes await this.accountRepo.save(fromAccount); await this.accountRepo.save(toAccount); // Cross-cutting concerns via interfaces this.audit.logTransfer(fromAccount, toAccount, amount); if (amount.exceeds(Money.of(10000, amount.currency))) { await this.notifications.notifyLargeTransaction(fromAccount, amount); } } catch (e) { if (e instanceof InsufficientFundsError) { await this.notifications.notifyOverdraft(fromAccount, amount); this.audit.logFailedTransfer(fromId, toId, e.message); } throw e; } } } // =============================================== // INFRASTRUCTURE LAYER - Implements interfaces // =============================================== // The domain doesn't know these exist at compile time class PostgresAccountRepository implements IAccountRepository { /* ... */ } class EmailNotificationService implements INotificationService { /* ... */ } class FileAuditLogger implements IAuditLogger { /* ... */ }43:["$","$L62",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792309763881,"state":{"data":{"json":{"id":"seed_40bf4bd62218058132407aa5d5c2af10","slug":"onion-architecture","category":"System Design (LLD)","topic":"Onion Architecture","title":"Onion Architecture: Domain-Centric System Design","description":"Master Onion Architecture, a powerful approach to organizing code that places domain logic at the center while pushing infrastructure to the edges. Learn to build systems that are testable, maintainable, and resilient to technological change.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_816da432552d55683e46873fd9691c64","title":"Core at Center, Infrastructure at Edge","order":0,"content":[{"id":"opening-hook","title":"The Architecture That Protects Your Domain","content":[{"data":{"content":"In 2008, Jeffrey Palermo introduced **Onion Architecture**, a revolutionary approach to structuring applications that challenged the traditional layered architecture paradigm. At its heart lies a simple but profound insight: **your domain logic—the rules and behaviors that define your business—should never depend on infrastructure concerns like databases, web frameworks, or external services**.\n\nThis seemingly simple principle has far-reaching implications. It means your core business logic can be tested without a database. It means you can switch from PostgreSQL to MongoDB without touching domain code. It means your application's most valuable intellectual property—its business rules—is protected from the volatility of technology choices."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the fundamental structure of Onion Architecture, why the domain sits at the center, how dependencies flow inward toward this core, and why infrastructure is deliberately pushed to the outer edges of your system.","variant":"info"},"type":"callout"}]},{"id":"problem-with-traditional-layering","title":"The Problem with Traditional Layering","content":[{"data":{"content":"To understand why Onion Architecture matters, we must first understand what it addresses. Traditional N-tier architecture organizes applications into horizontal layers:\n\n```\n┌──────────────────────────────────┐\n│ Presentation Layer │\n├──────────────────────────────────┤\n│ Business Layer │\n├──────────────────────────────────┤\n│ Data Access Layer │\n├──────────────────────────────────┤\n│ Database │\n└──────────────────────────────────┘\n```\n\nIn this model, each layer depends on the layer directly below it. The Presentation Layer calls the Business Layer, which calls the Data Access Layer, which communicates with the Database.\n\n**The fatal flaw**: Dependencies flow *downward toward infrastructure*. Your business logic—the most valuable part of your system—depends on the database layer. This creates several serious problems:"},"type":"text"},{"data":{"items":["**Database Coupling** — Business logic is tightly coupled to database schemas, stored procedures, and query patterns. Schema changes ripple upward into business code.","**Testing Difficulty** — Testing business logic requires a real or mocked database. Unit tests become slow integration tests, or complex mock setups obscure what's being tested.","**Technology Lock-in** — Switching databases, ORMs, or data access patterns requires rewriting business layer code. The cost of change is prohibitive.","**Infrastructure Bleed** — Database concerns (transactions, connection management, caching) leak into business logic, complicating what should be pure domain operations.","**Architectural Erosion** — Over time, developers take shortcuts. Business logic migrates into stored procedures, or UI components call the database directly."],"title":{"icon":"XCircle","text":"Problems with Traditional Layering","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Coupling Cascade","content":"When your business layer depends on your data layer, every database decision becomes a business layer decision. Need to add a new index? It might change query patterns the business layer relies on. Want to split a table? You'll refactor business code too. The database—which should be an implementation detail—becomes a controlling force over your entire architecture.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"the-onion-insight","title":"The Onion Insight: Inverting Dependencies","content":[{"data":{"content":"$63"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Dependency Rule","content":"The fundamental rule of Onion Architecture: **Source code dependencies can only point inward.** Nothing in an inner circle can know anything about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by code in an inner circle—whether classes, functions, variables, or any other named software entity.","variant":"tip"},"type":"callout"},{"data":{"content":"**How does this work in practice?**\n\nConsider a `TransferFundsService` that moves money between accounts. In traditional architecture, this service might depend directly on a `SqlAccountRepository`. In Onion Architecture:\n\n1. The domain layer defines an `IAccountRepository` interface (what operations we need)\n2. The business service depends on `IAccountRepository` (an abstraction)\n3. The infrastructure layer provides `SqlAccountRepository` (concrete implementation)\n4. At runtime, dependency injection wires `SqlAccountRepository` to the interface\n\nThe critical insight: **the interface is defined in the inner circle, not the outer**. The domain owns the contract; infrastructure adapts to it."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"visualizing-the-onion","title":"Visualizing the Onion Structure","content":[{"data":{"content":"$64"},"type":"text"},{"data":{"type":"ordered","items":["**Domain Model (Innermost Core)** — The heart of the application. Contains entities, value objects, aggregates, and domain events. Represents the fundamental business concepts and rules. Has *zero* external dependencies.","**Domain Services** — Operations that don't naturally belong to a single entity. Cross-entity business logic, domain calculations, invariant enforcement. Still within the domain, still no infrastructure dependencies.","**Application Services** — The use cases of the application. Orchestrates domain objects to implement specific application behaviors. Defines interfaces for external resources (repositories, messaging).","**Infrastructure (Outermost Layer)** — Everything else: databases, web frameworks, external APIs, file systems, email services, IoC containers. Adapters that implement interfaces defined by inner layers."],"title":{"icon":"Target","text":"The Four Primary Layers","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The critical observation**: As you move from the center toward the edge, the code becomes:\n- More volatile (frameworks change faster than domain rules)\n- More dependent on external factors (network, disk, third parties)\n- Easier to replace (infrastructure is pluggable)\n- Less valuable to the business (databases are commodities; domain logic is intellectual property)\n\nBy placing the most stable, most valuable, most business-specific code at the center and the most volatile, most replaceable code at the edge, we create architectures that age gracefully."},"type":"text"}],"titleType":"number","titleNumber":3},{"id":"domain-model-core","title":"The Domain Model Core","content":[{"data":{"content":"The innermost circle—the Domain Model—is the most protected part of your application. It contains the pure business logic: the rules, behaviors, and concepts that exist independent of any technology choices.\n\n**What lives in the Domain Model:**"},"type":"text"},{"data":{"items":["**Entities** — Objects with identity that persists through time. A `Customer`, an `Order`, an `Account`. Identity matters more than attributes.","**Value Objects** — Immutable objects defined purely by their attributes. A `Money` object, an `Address`, a `DateRange`. Two values are equal if their attributes are equal.","**Aggregates** — Clusters of entities and value objects treated as a unit for data changes. Each aggregate has a root entity that controls access to the cluster.","**Domain Events** — Record of something meaningful that happened in the domain. `OrderPlaced`, `PaymentReceived`, `AccountOverdrawn`.","**Repository Interfaces** — Abstractions for retrieving and storing aggregates. Defined here, implemented in infrastructure."],"title":"Domain Model Components","variant":"accent"},"type":"list"},{"data":{"fileName":"Domain Model Core Example","languages":[{"code":"$65","label":"TypeScript","value":"typescript"},{"code":"$66","label":"Java","value":"java"}]},"type":"code"},{"data":{"icon":"Info","title":"Domain Purity","content":"Notice what's *not* in this code: SQL queries, HTTP requests, JSON parsing, framework annotations. The domain model is pure business logic. It doesn't know how it's persisted, transported, or presented. This purity is what makes it testable, portable, and durable.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"infrastructure-edge","title":"The Infrastructure Edge","content":[{"data":{"content":"The outermost layer is Infrastructure: everything that isn't your core domain logic. This is where \"messy\" code lives—HTTP parsing, database connections, file I/O, third-party API calls. But crucially, this code is **isolated from your domain** and can be changed or replaced without affecting business logic.\n\n**What lives in the Infrastructure layer:**"},"type":"text"},{"data":{"items":["**Repository Implementations** — Concrete classes that implement repository interfaces using specific technologies (SQL, MongoDB, in-memory).","**Web Controllers/Handlers** — HTTP request handling, route definitions, request/response transformation.","**External Service Adapters** — Clients for third-party APIs, messaging systems, email services.","**Persistence Configuration** — ORM mappings, database connection pools, migration tooling.","**IoC Container Setup** — Dependency injection configuration, service registration, lifecycle management.","**Cross-cutting Concerns** — Logging implementations, metrics collection, distributed tracing."],"title":"Infrastructure Components","variant":"glass"},"type":"list"},{"data":{"fileName":"Infrastructure Implementation Example","languages":[{"code":"$67","label":"TypeScript","value":"typescript"},{"code":"$68","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"**Key observations about infrastructure code:**\n\n1. **It depends on the domain** — The repository implements `IAccountRepository`, an interface *defined in the domain*\n2. **It adapts external formats** — Database rows are transformed to domain objects; HTTP requests become method calls\n3. **It's replaceable** — You could swap `PostgresAccountRepository` for `MongoAccountRepository` without touching domain code\n4. **It contains technical details** — SQL queries, JPA annotations, HTTP status codes—all the \"infrastructure noise\" is here"},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"why-infrastructure-at-edge","title":"Why Infrastructure at the Edge?","content":[{"data":{"content":"Pushing infrastructure to the edge isn't an arbitrary design choice—it's a strategic response to the forces that shape software systems over time."},"type":"text"},{"data":{"left":[{"data":{"items":["**Technology Agility** — Databases, frameworks, and cloud services change. Edge placement lets you adopt new technology without domain rewrites.","**Pure Domain Testing** — Domain logic can be unit tested with simple mocks or fakes. No database spinup, no HTTP servers.","**Clean Business Logic** — Domain code reads like business documentation, not technical specification.","**Team Separation** — Domain experts can work on core logic while infrastructure specialists handle integrations."],"title":{"icon":"CheckCircle","text":"Benefits of Edge Infrastructure","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Risk Isolation** — If a third-party API changes, only the adapter layer is affected. Domain logic remains stable.","**Vendor Flexibility** — Not locked to a specific cloud provider, database vendor, or framework ecosystem.","**Investment Protection** — Domain logic—your competitive advantage—persists across technology generations.","**Simpler Reasoning** — Each layer has clear responsibilities. Debugging is more focused."],"title":{"icon":"Target","text":"Strategic Advantages","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"The Volatility Gradient","content":"Think of the onion layers as a volatility gradient. The core changes least frequently (business rules are stable). The edge changes most frequently (frameworks update, APIs evolve, databases migrate). By aligning code organization with volatility, you minimize the impact of change: volatile code is easy to replace, stable code is protected from disruption.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"role-of-interfaces","title":"The Role of Interfaces: Defining Contracts","content":[{"data":{"content":"Interfaces are the architectural mechanism that enables inward-only dependencies. They serve as contracts between layers, with a crucial placement rule: **interfaces are defined in inner layers and implemented in outer layers**.\n\nThis placement is non-negotiable. If the interface were defined in the infrastructure layer, the domain would depend on infrastructure—violating the core principle."},"type":"text"},{"data":{"fileName":"Interface Placement and Ownership","languages":[{"code":"$69","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"rows":[["Creates Interfaces","Yes - defines contracts for what it needs","No - only implements contracts"],["Depends On","Its own interfaces","Inner layer interfaces"],["Knows About","Domain concepts only","Domain concepts + specific technologies"],["Compile-time Coupling","Zero to outer layers","Coupled to interface definitions"],["Replaceability","Must remain stable","Easily swappable"]],"caption":"Interface Ownership in Onion Architecture","headers":["Aspect","Inner Layer (Domain/Application)","Outer Layer (Infrastructure)"]},"type":"table"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: The Onion Structure","content":[{"data":{"content":"We've established the fundamental structure and philosophy of Onion Architecture. Let's consolidate the key principles:"},"type":"text"},{"data":{"type":"ordered","items":["**Domain at the center** — The innermost layer contains pure business logic: entities, value objects, aggregates, domain events. It has no infrastructure dependencies.","**Infrastructure at the edge** — The outermost layer contains all technology-specific code: databases, web frameworks, external services, configuration.","**Dependencies flow inward** — Each layer may only depend on layers inside it. The infrastructure depends on the domain, never vice versa.","**Interfaces enable inversion** — Contracts are defined in inner layers, implemented in outer layers. This is the mechanism that reverses traditional dependency direction.","**Volatility increases outward** — The most stable code (business rules) sits at the center; the most volatile code (frameworks, integrations) sits at the edge.","**Testability by design** — Domain logic can be tested without infrastructure. Dependency injection enables mock/fake substitution at boundaries."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand the basic structure—core at center, infrastructure at edge—we'll dive deeper into the specific layers of Onion Architecture. In the next page, we'll examine each layer in detail: what belongs there, how layers communicate, and the dependency rules that govern their relationships."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamental structure of Onion Architecture: domain-centric design with dependencies flowing inward and infrastructure pushed to the edge. This inversion of traditional layering protects your domain from technology volatility and creates systems that are testable, maintainable, and resilient to change.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1","title":"Layers and Dependencies","order":1,"content":null,"isLocked":true},{"id":"seed_6467a3ae6be52b5db4d4b98329e6acba","title":"Comparison with Hexagonal Architecture","order":2,"content":null,"isLocked":true},{"id":"seed_537ea1861d043b20a63eb5993e0287b6","title":"Onion Architecture in Practice","order":3,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792309763876,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"onion-architecture"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"onion-architecture\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309763882,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309763874,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_40bf4bd62218058132407aa5d5c2af10"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_40bf4bd62218058132407aa5d5c2af10\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309763882,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309763874,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","get"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309763882,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309763874,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","getUserLike"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309763882,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792309763874,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["highlights","getHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309763882,"state":{"data":"$undefined","dataUpdateCount":0,"dataUpdatedAt":0,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"pending","fetchStatus":"fetching"},"queryKey":[["highlights","getPopularHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_0fdfe52eb4b4bac052f04f3ecb4e9fd1\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@6a"}]},"children":"$L6b"}]