La conception est rarement 100% correcte ou 100% incorrecte. Il est préférable de commencer à poser des questions sur votre conception, à remettre en question vos décisions et à vous forcer à raisonner par une défense logique. Par exemple, j'ai l'impression d'avoir un PersonDTO redondant par exemple. Pourquoi ne pouvez-vous pas simplement utiliser l'entité Personne pour les deux opérations? Il a presque tous les mêmes champs de données que votre objet DTO. Maintenant, lorsque vous changez la personne, vous devrez mettre à jour deux classes. DDD suggère également que le meilleur endroit pour la logique Factory et Repository est dans la classe Entity elle-même. Par exemple, votre objet Person peut avoir une méthode d'instance appelée save() qui conserve les modifications apportées à la base de données. L'argument contre cette habitude était que la persistance était généralement beaucoup de travail (pensez à tout ce ORM) donc il devrait (à juste titre) être séparé. Les API de persistance modernes telles que JPA, JCR et les frameworks tels que Hibernate, NHibernate, TopLink, etc. font de la persistance d'une entité un interligne. De même, vous pouvez amener votre Usine dans l'Entité Personne en en faisant une méthode d'usine statique (classe). Ces changements sont facultatifs, mais l'idée est qu'une personne devrait savoir comment construire et persister.
Enfin, avoir une couche Service est un peu controversée. Vous avez quelques grands de OOD comme Martin Fowler qui n'utilisent jamais une couche de Service (cette logique appartient au domaine), mais défend en même temps ceux qui choisissent de le faire. J'ai trouvé la couche Service utile en tant que couche transactionnelle et couche d'exportation API (pensez à ouvrir votre API Service à RMI ou aux services Web).