Where we do perhaps differ is in how we perceive the contents of the middle hexagon. By putting the database into the middle hexagon I am not implying that the domain objects will necessarily depend on it. There will be many clusters (to use a nice Eiffel term) of objects in the middle hexagon, with many and varied dependencies among them. I’m arguing that the persistence mechanism will be one such cluster, and I would hope that solid use of TDD will render it replaceable with mocks.

In persistence stories arrive late I note that the persistence model is naturaly something we’ll add fairly late (assuming we’re following the agile way and developing in order of decreasing value). It seems to me that this – and TDD – will naturally lead to the domain objects being independent of their persistence architecture.

In my experience, the best way to build your domain model for a hexagonal architecture is to start with verb-oriented “command” or “service” objects, and factor out domain objects as they are needed to avoid duplication. For example, you might have a class called CreateAccount which contains all the data needed to create a new user account on the system. You might also have an “UpdateAccount” command, and you might find that they both need the same information, then you would create a class “Account”. Iff you have complex account related domain logic (as opposed to presentation or persistence logic) you should add it to your account class.

It sounds a little like you are headed back to the layered, or even client-server architecture if you don’t keep your persistence code at a good distance from your domain logic.