我有一个DTO和实体，例如PersonDTO和Person。 我使用DDD创建了一个aaplication PersionApplciation，它将DTO作为输入并在内部调用PersonService。 在PersonService中，我使用PersonFactory获取Person的实例（仅从DTO填充并将值设置为Person实体）。获取Person的实例后，我调用personRepository的add方法将记录保存到DB中。 再次在查询方法中，我必须将DTO返回给personApplication。为此我使用personService中的方法我调用PersonRepository，它加载Person实体并填充personDTO并将personDTO返回给personService，personService将DTO返回给personApplication。
我的做法是对还是错？
答案 0 :(得分：1)
设计很少100％正确或100％错误。最好开始询问有关您的设计的问题，挑战您的决定并强迫自己通过逻辑辩护来推理。
例如，我觉得PersonDTO是多余的。为什么不能只将Person实体用于这两个操作？它几乎肯定拥有与DTO对象相同的所有数据字段。现在当你更改Person时，你将不得不更新两个类。
DDD还建议工厂和存储库逻辑的最佳位置在Entity类本身内。例如，您的Person对象可以有一个名为save（）的实例方法，该方法会保留对数据库的任何更改。反对这种情况的论据曾经是持久性通常是很多工作（想想所有的ORM）所以它应该（理所当然地）被分离出来。现代持久性API（如JPA，JCR和Hibernate，NHibernate，TopLink等框架）使实体的持久性成为一个单行。同样，您可以将Factory作为静态（类）工厂方法，将其带入Person Entity。这些更改是可选的，但想法是Person应该知道如何构建和持久化。
最后，拥有服务层有点争议。你有一些像马丁福勒这样的OOD伟人，他们从不使用服务层（这个逻辑属于域名），但同时也会捍卫那些选择的人。我发现服务层可用作事务层和API导出层（想想将服务API打开到RMI或Web服务）。