Unit Of Work Implementer

Implement Unit of Work (UoW) — the object that tracks new, dirty, clean, and removed entities during a business operation and commits all database changes together in the correct order. Use when asked: "how do I implement Unit of Work?", "how does Hibernate Session work under the hood?", "how do I avoid N+1 writes?", "how should I structure DbContext scoping?", "SQLAlchemy session management best practices", "EntityManager lifecycle", "ORM session management", "how to track entity changes in a Data Mapper layer?", "first-level cache", "identity map implementation", "object change tracking", "persistence coordination", "commit ordering with foreign keys", "how does EF Core SaveChanges work?", "dirty tracking", "how to batch database writes?", "UoW pattern implementation", "Hibernate Session vs EntityManager", "SQLAlchemy Session scope", "DbContext per-request", "entity state tracking". Applies when a Data Mapper pattern is in place (or being introduced) and the team needs disciplined change tracking, ordered commits, and first-level caching across a business operation. Integrates with Identity Map for cache and identity consistency. Integrates with Optimistic Offline Lock via version-conditioned UPDATE. Prerequisite: Data Mapper must be the chosen data-source pattern; UoW does not apply cleanly to Active Record (AR handles per-object persistence without a coordinator). If the data-source pattern has not been chosen, invoke `data-source-pattern-selector` first.

View on ClawhHubView on GitHub

Install

Claude CodeClawhHubnpxCursorCodexGemini CLI

1. Add marketplace

› /plugin marketplace add bookforge-ai/bookforge-skills

2. Install plugin

› /plugin install patterns-of-enterprise-application-architecture@bookforge-skills

3. Use the skill

› /unit-of-work-implementer

CC-BY-SA · Open sourceGitHub

Source Book

Patterns of Enterprise Application Architecture

Martin Fowler, David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, Randy Stafford

More from Patterns of Enterprise Application Architecture

Anti Patternshybrid

Data Access Anti Pattern Auditor

Audit a persistence layer and schema for data access anti-patterns: N+1 query (SELECT N+1), ripple loading, lazy loading anti-pattern, ghost/proxy identity trap (missing Identity Map), Active Record anti-pattern on non-isomorphic schema, Active Record / Data Mapper mismatch, Serialized LOB overuse (queryable data stored in BLOB/JSONB/TEXT), meaningful primary key leakage, business logic in Gateway classes. Given a codebase and schema, produces a prioritized anti-pattern inventory with code location, evidence snippet, consequence, and remediation that cross-references pattern-selector skills. Use this for ORM performance audit, ORM anti-pattern detection, persistence anti-pattern inventory, database access anti-pattern review, persistence layer review, data access review, audit persistence layer.

+57%

Data Accesshybrid

Data Source Pattern Selector

Choose the right data access pattern — Table Data Gateway, Row Data Gateway, Active Record, or Data Mapper — for a persistence layer. Use when asked "should I use Active Record or Data Mapper?", "which ORM pattern fits my app?", "when does Hibernate-style mapping make sense vs. Rails ActiveRecord?", "how do I structure my database access layer?", "data mapper or active record for my domain model?", "Row Data Gateway vs Active Record", "Table Data Gateway vs Data Mapper", "Fowler data source patterns", "persistence layer design", "ORM pattern selection", "choose ORM pattern", "database access layer architecture", "Hibernate vs Rails persistence style". Applies when designing a new persistence layer or refactoring an existing one. Routes each domain-logic pattern (Table Module, Transaction Script, Domain Model) to its natural data-source counterpart. Identifies the Active Record / Data Mapper mismatch anti-pattern (AR when schema is not isomorphic with objects; DM when AR would suffice). Maps each pattern to modern framework idioms: Rails ActiveRecord → AR pattern; Hibernate / Spring Data JPA / EF Core → DM; Django ORM → AR-leaning; SQLAlchemy Core → TDG-style; SQLAlchemy ORM → DM; Laravel Eloquent → AR. Warns against business logic creeping into Gateway classes. Produces a pattern decision record with rationale, framework notes, and migration path. If the domain-logic pattern has not yet been chosen, invoke `domain-logic-pattern-selector` first.

+64%

Distributed Systemshybrid

Distribution Boundary Designer

Distribution design for enterprise systems: decide whether to distribute, where to draw the service boundary, and how to implement it with Remote Facade and Data Transfer Object (DTO). Use when deciding microservices vs monolith, evaluating process boundaries, extracting services, designing remote APIs, choosing coarse-grained API shape, preventing distribution-by-class anti-pattern, applying Fowler's First Law of Distributed Object Design, designing service extraction strategy, determining when distribution is warranted vs cargo-culting microservices, implementing Remote Facade pattern, designing DTOs independent from domain objects, choosing between gRPC vs REST vs message queue vs GraphQL for service boundary, monolith decomposition, service boundary design, remote API design, distribution strategy, when to distribute, process boundary decision, coarse-grained interface design.

+77%

Domain Logichybrid

Domain Logic Pattern Selector

Choose domain logic pattern for enterprise application subsystems: Transaction Script vs Domain Model vs Table Module, and decide Service Layer thickness. Use when organizing business logic, choosing between procedural service methods and rich domain models, selecting enterprise app architecture, routing domain logic to the right pattern, deciding anemic domain model vs rich domain model, applying Fowler's complexity-vs-effort curve, determining when to use Domain Model, when to use Transaction Script for simple CRUD, when Table Module fits .NET RecordSet environments, deciding Service Layer facade vs operation script vs controller-entity, avoiding transaction-script-sprawl, avoiding anemic-domain-model anti-pattern, preventing stored-procedure logic leakage, structuring enterprise app business logic, domain logic organization, choose domain pattern, enterprise app business logic design.

+54%