With an understanding of conceptual object design, we need to apply all the concepts to our domain. We continue modeling the prisoner transfer we started. So far, we have an entry point to the application module that will ultimately handle this. From the tests, we know that the prisoner transfer relies on a prisoner and a dungeon object.
So let's walk through what the prisoner transfer needs to do and what its collaborators are. Previously, we identified that the prisoner transfer will need a prisoner, obviously, and a target dungeon to transfer to, and the prisoner transfer should manage everything else. It is important to think about what the minimal input is from a user perspective to limit the API surface.
Of course the prisoner transfer, which is a service in DDD speak, needs more collaborators to really fulfill its purpose. First is a reference to the local dungeon to acquire resources such as orcs to act as keepers...