Design – Mixing Fowlers Transaction Script and Domain Model

According to Patterns of Enterprise Application Architecture, you can use a Table Data Gateway with the Transaction Script pattern (see the "When To Use It" section of the Table Data Gateway pattern). So your approach seems like a pretty conservative way to move towards better code without radically changing the original style all at once - which is a good thing.

The refactoring should be pretty straightforward as well - you are just going to pull the database logic in the Person class into a PersonGateway class. Admittedly you can't simultaneously refactor all the Transaction Script classes, but that's unavoidable. You probably won't even have to break their API, so I wouldn't worry too much about the fact that for a while some scripts will use gateway classes and some won't.

I think making that change is a better approach than not making it.

There is one thing I don't like about your design. And that is fact you are going to have 3 additional classes for each aggregate root (Factory, Mapper, Repository) with semi-duplicate code in form of reading and setting properties everywhere. This will be problematic as you add and remove properties, because forgetting to change a single method might cause an error. And the more complex the domain entity is, the more of this duplicate code is. I don't want to see CompanyFactory.CreateExisting when company has 10 properties and 2 entities in aggregate.

Second thing I might complain about is the IdentityFactory. In DDD, the identity should either be related to domain, in which case you set it to some calculated value. Or it is transparent, in which case you can have DB take care of it. Adding some kind of factory for identity is IMO overenginering.

I also don't like the mapping. While I agree it might not be possible to use EntityFramework directly, you could at least try. EF is getting better with POCO lately and you might be surprised how powerfull it is. But it still isn't NHibernate. If you really want to create separate models, try thinking about using some auto-mapping library.

It is nice you are demoing the design on one simple class, but try also demoing or at least imagining how the design will work with dozens of aggregates that have lots of properties and entities. Also, write a code that will use this design. You might realize that while the design might look good from the inside, it is cumbersome to use from the outside. Also, no one here is going to tell you if the design is appropriate for your team and your domain.