In domain driven design
- A repository is a collection like "interface" that hides data source access. It furnish add, remove and retrieval method just like a collection would. It does it using domain language.
- The application layer uses the repositories by thinking about them as collection, by retrieving from it or adding items to it, but should not be aware of whether a specific item is being persisted or not.
- domain layer should guard domain rules
With those rules in mind: How can entities updates be persisted and should the repository return self persisting entities ?
Example:
Domain
enum Status { awaitingApproval, accepted, declined } class Order { Status _status; // private Status get status => _status; // point 3. Protects domain rules set status(Status updatedStatus) { if (status != awaitingApproval) { throw 'cannot update a $status order'; } status = updatedStatus; } } Application
// aggregate root class User { OrderRepository _ordersRepository; Future<List<Order>> viewAllOrders() => _ordersRepository.selectAll(); // point 2. the application layer is not aware of whether the order update is persisted or not. Future<void> acceptOrder(Order order) => order status == Status.accepted; } Repository
class ConcreteOrderRepository { Future<List<Order>> selectAll() async => inMemoryStorage.selectAll('orders'); // point 1. No update method on a collection like object. } There is still something missing here: How is the update to the Order being persisted ?
I've seen two version to resolve this architectural issue:
- add an update method the the repository which has as side effects:
- You can't think of the repository as a collection, it is now an abstraction over persistence. This is imo a very distinct concept of the original intent of repositories.
- The application layer is now aware it is using persistence as it has to explicitely call
orderRepository.update(order)..
- The second solution I've seen is to use an ORM framework and adding a bunch of annotation in the domain layer.
@Entity()comes to mind. I believe this is the worst solution of the bunch as it polutes the domain layer.
A third solution that I've not seen is to return a PersistedOrder instead of an order to the application layer:
class PersistedOrder extends Order { final OrderDataSource orderDataSource; factory fromOrder(OrderDataSource dataSource, Order order) { return PersistedOrder(dataSource, status: order.status) } @override status(Status status) { super.status = status; orderDataSource.updateOrder(super.id, this); } } class ConcreteOrderRepository { final OrderDataSource orderDataSource; Future<List<Order>> selectAll() async { final allOrders = orderDataSource.selectAll(); return allOrders.map((order) => PersistedOrder.fromOrder(order)); } } This seems to be in line with point 1, 2 and 3. Only the Persistence layer knows that the Order is in fact a PersistedOrder, other layers just use an order and an orderRepository as a collection where they can retrieve and add elements.
Still, somewhat of a red flag for me is that I've not seen anyone do this, so there might be a reason. Which is what this question is about:
- Have anyone encountered this pattern ? Does it have a name ?
- What would be / are possible draw backs here ?
