Unit of work is A Martin Fowlers design (architectural) pattern, to handle [transactional](https://www.buzzchart.info/post/acid-in-database-transactions) changes in the code.

This is the quote from his book:

> Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.Martin fowler

Unit of work collects all changes about domain objects, that need to be synced (with the database) and lets committing those at the end of a (business) [transaction](https://www.buzzchart.info/post/acid-in-database-transactions). Tracking and syncing objects (shared state) is crucial feature. Syncing can be done more frequently, at any change, but it may have negative impact on a performance. Another reason using this pattern, is making changes atomic(all or nothing).

I found this pattern not only solving concurrency problems. I think, it also solves the state synchronization problem between two "objects". In examples below, these two modules are database and client. Unit of work synchronizes runtime objects loaded and created in the database. This pattern allows collecting changes and committing those in one atomic operation. It allows having [consistent](https://www.buzzchart.info/post/cap-theorem) state between two modules in the system.

Though alone this pattern does not complies totally with the [ACID](https://www.buzzchart.info/post/acid-in-database-transactions) database transaction, but it allows having A and C from the [ACID](https://www.buzzchart.info/post/acid-in-database-transactions).

There is no strict schema, how to use the instance of "Unit of Work" (UoW later).

- You may have a separate class to register changes and then get changes on a commit method.

- You may have a reference to a repository, which is able to commit all the changes.

- In case you are using the "[Domain model](https://www.buzzchart.info/post/domain-model-vs-transaction-scripts)" pattern, then domain object knows how to make changes in the database.

_Patterns of Enterprise Application Architecture: Martin Fowler, with Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford_

_Note: The content in this article is a summary/interpretation inspired by them. Proper attribution is given to the respective authors._

Unit of Work

ACID (Atomicity, Consistency, Isolation, Durability) in IT is a properties of a business (or database) transactions, that guarantees the reliability and data integrity of the transaction.

- **Atomicity** - transaction as one unit. If one operation of transaction fails, the transaction is failed

- **Isolation** - concurrent transactions are shielded form the "effects" of other transactions

- **Consistency** - from one consistent database state to another to another consistent database state

- **Durability** - guarantees that once a transaction is committed, changes will survive any system failures