Infrastructure layer¶

The Infrastructure layer provides concrete implementations of the interfaces defined in the Domain Layer. It handles all external concerns - database access via Entity Framework Core, repository implementations, and service integrations.

Clean Architecture - outermost layer

Infrastructure depends on Domain (it implements Domain interfaces) but Domain never knows about Infrastructure. This means you can swap the database or change how data is stored without touching any business logic.

Responsibility¶

Data access: Entity Framework Core implementation, including PetfolioDbContext, value object conversions, and database schema definitions
Repository implementations: Concrete data access classes (e.g. EntityRepository implementing IEntityRepository)
Unit of Work: Coordinates persistence operations across repositories, managing transaction boundaries via SaveChangesAsync
EF Core configurations: Table mappings, relationships, indexes, and value conversions
Service implementations: Implementations of domain service interfaces (e.g. CurrentUserService implementing both ICurrentUserService and ITenantProvider).

Components¶

graph TB
    subgraph "Data access"
        DBC["PetfolioDbContext<br>DbSet&lt;Account&gt;<br>DbSet&lt;User&gt;<br>DbSet&lt;Animal&gt;<br>SaveChangesAsync"]
    end

    subgraph "EF Core configurations"
        CFG1[AccountConfiguration<br>Table mapping<br>Relationships<br>Indexes]
        CFG2[AnimalConfiguration<br>Value object conversions<br>Owned Weight records]
        CFG3[UserConfiguration<br>Email index<br>OAuth indexes]
    end

    subgraph "Repository implementations"
        REPO1[AnimalRepository<br>implements IAnimalRepository]
        REPO2[AccountRepository<br>implements IAccountRepository]
        REPO3[UserRepository<br>implements IUserRepository]
        REPO4[UnitOfWork<br>Transaction coordination]
    end

    DBC --> CFG1
    DBC --> CFG2
    DBC --> CFG3

    REPO1 --> DBC
    REPO2 --> DBC
    REPO3 --> DBC
    REPO4 --> DBC

    DBC --> DB[(MySQL Database)]

Repository pattern¶

Repositories abstract data access behind the interfaces defined in the Domain Layer. The Infrastructure layer provides the concrete implementations using Entity Framework Core.

classDiagram
    class IEntityRepository {
        <<interface>>
        +GetByIdAsync(Guid id, CancellationToken ct) Task~Entity?~
        +GetAllAsync(CancellationToken ct) Task~List~Entity~~
        +CreateAsync(Entity Entity, CancellationToken ct) Task
    }

    class EntityRepository {
        -PetfolioDbContext _context
        +EntityRepository(PetfolioDbContext context)
        +GetByIdAsync(Guid id, CancellationToken ct) Task~Entity?~
        +GetAllAsync(CancellationToken ct) Task~List~Entity~~
        +CreateAsync(Entity Entity, CancellationToken ct) Task
    }

    class IUnitOfWork {
        <<interface>>
        +SaveChangesAsync(CancellationToken ct) Task~int~
    }

    class UnitOfWork {
        -PetfolioDbContext _context
        +UnitOfWork(PetfolioDbContext context)
        +SaveChangesAsync(CancellationToken ct) Task~int~
    }

    IEntityRepository <|.. EntityRepository
    IUnitOfWork <|.. UnitOfWork

    classDef service fill:#4a90d926,stroke:#4a90d9,stroke-width:2px

    class IEntityRepository service
    class EntityRepository service
    class IUnitOfWork service
    class UnitOfWork service

Diagram key

Class	Style	Meaning
`service`	Light blue fill, blue border	Interface or implementation

Unit of Work¶

The Unit of Work pattern coordinates database transactions. Repository methods add entities to the EF Core context without saving - the handler in the Application Layer decides when to commit by calling SaveChangesAsync on IUnitOfWork.

DO: Use IUnitOfWork to manage transaction boundaries in the Application layer

DON'T: Reference DbContext directly in Application layer or save in repositories