DDD abstraction over infrastructure code - scala

Question

I am creating a repository in my project which will be responsible for all storage operations for a User entity. I will use mongo as the db and mongoreactive as the client. The problem which I have now is about types.
trait UserRepository {
save(user: User) : ?
}
trait MongoUserRepository extends UserRepository {
save(user: User) : Future[WriteResult] = {
collection.insert(user)
}
}
How in my domain should I model WriteResult which comes from MongoReactive? I do not want it to leak into my domain. Is there any existing pattern or a good practice?

Answer 1

How in my domain should I model WriteResult which comes from MongoReactive? I do not want it to leak into my domain. Is there any existing pattern or a good practice?
The usual practice is that the domain would define the UserRepository trait as a service provider interface (spi) that the persistence infrastructure would need to support. Fundamentally, it's a way of expressing the usage requirements that the model imposes on persistence.
Using the language of Command Query Separation, save is a command: it's an operation that changes the state of the repository. So the implementation of the trait should conform to your local coding standard for implementing a command.
Greg Young on (generic) repositories:
What exactly was the intent of the repository pattern in the first place? Looking back to [DDD, Evans] one will see that it is to represent a series of objects as if they were a collection in memory so that the domain can be freed of persistence concerns. In other words the goal is to put collection semantics on the objects in persistence.
So you could also to your collections library for inspiration.
But generally speaking, the most common choice would look like
trait UserRepository {
save(user: User) : Unit
}
So that is the contract your specific implementations would be expected to satisfy.
In MongoUserRepository, you adapt the implementation of your persistence solution to satisfy the contract. In this case that would mean unpacking the Future, inspecting the WriteResult for errors, and throwing an exception if the write was unsuccessful.
With save(user: User) : Unit you implicitly put a requirement on your clients to watch for repository failure (for example: in case of db failure)
Other way around - the repository is a service provider interface; this design doesn't constrain the clients, but the providers. In the lingo of hexagonal architecture, I'm defining a secondary port and constraining the secondary adapter to conform to the contract of the port.
The motivation is exactly the one you describe: the repository consumer is supposed to be isolated from the protocol required to interact with the selected persistence solution. The domain model sits in the middle of the business universe, and the adapter insulates the business universe from reality.
Evans Chapter 6 raises the management challenge of "preventing the model from getting swamped by the complexity of managing the (domain object) life cycle". Repositories provide "the means of finding and retrieving persistent objects while encapsulating the immense infrastructure involved.
The repository is a firewall.
What we are addressing here is separation of concerns; the domain model describes your business logic. We want to be able to see the business case clearly, and that's not going to be possible if we have to explicitly manage what happens in the event that a mutable, in memory, collection fails catastrophically on modification. The pragmatic answer is to nope out and let the application handle it.
That said... I deliberately hedged above when I wrote "conform to your local coding standard". If your local guidelines use railway oriented programming, or message driven, then by all means line it up. There's absolutely no reason why the domain model should care whether storage is synchronous or asynchronous, local or remote, etc.
But if your domain model starts to fill up with match expressions that describe implementation concerns, I'd say you've lost the plot somewhere.

Answer 2

When I was implementing the same repository, I ended up extracting WriteResult value I was most interested in. In my case I ended up with the following signature:
trait UserRepository {
save(user: User) : Future[Option[String]]
}
which returns either some error message or nothing. As a result implementation will be like this:
trait MongoUserRepository extends UserRepository {
save(user: User) : Future[Option[String]] = {
collection.insert(user).map(_.errmsg)
}
}
I ended up with this implementation because I do not lose exception message in case of exception.
Alternative options could be to map insertion result to Boolean:
trait UserRepository {
save(user: User) : Future[Boolean]
}
trait MongoUserRepository extends UserRepository {
save(user: User) : Future[Boolean] = {
collection.insert(user).map(_.ok)
}
}
But in this case you will lose exception message. Sometimes it can be fine however it depends on your exact case.
UPDATE: The answer posted above is valid for 0.11 version. In 0.12 method errmsg in WriteResult was removed. Alternatively you can use writeErrors and in case Seq is not empty you extract all errmsgs from all WriteError.
Hope it helps, sir!