However, to raise a similar issue, one I have seen debated elsewhere, if you extend this logic, then shouldn’t you put into a persisted object the ability to persist itself? In other words, if I have a Domain Object whose state is persisted to a database, should that domain object no contain the knowledge to retrieve and store its state from/to the database? This would seem like a logic extension of the above argument?

The problem with this, that most people argue, is that you want to abstract the state of an object away from how it is persisted. This allows you to change the persistence mechanism (e.g., flat files instead of a database) without the domain object knowing about the change. I think in my case, a similar argument could be made.

I just find it tough to figure out when the abstraction is required and when direct knowledge is required (if that makes any sense).

aDirectorySpec.create() or aFileSpec.create() would create the actual entity if it did not exist.

aDirectorySpec.exists() or aFileSpec.exists() would identify if the entity existed.

These would take a name in the constructor (and directory ID, volume ID, etc., on MacOS 9). Could throw an exception for an invalid name, (or maybe I had it just drop or substitute characters and truncate to make the name valid. It’s been awhile.)