问题描述
有人可以解释吗？ 我正在尝试将wpf应用程序mvvm转换为不同的层（读取ddd）。我有些困惑
- 表示层（WPF，WEB，API）（好的。我知道）
- 实体模型（我知道是代表数据库表的类，例如 实体框架中的客户{id，name，surname，phone}
但以下内容使我感到困惑
- 域模型（是表示sql表列的类吗？例如 客户{Id，Name，Surname，phone}或对我有意义的类 应用程序，例如客户{ID，FullName，Balance}
- 域模型在哪里？在服务的哪一层（单独的dll？ 层？或在数据存储库dll中）
- DTO（数据传输对象）是否与域模型相同？
- 服务层（它是一个单独的dll吗？）
- 业务层（很多时候我看到“业务层”一词，有些 将其称为服务层）实际上是什么？一样吗是吗 不同的阶级？拥有它自己的另一个dll（层） 服务层以外的责任？
- 数据存储库（问题是，是否应在存储库所在的同一层中实现服务层或业务层）
以上所述，我已经制作了示例应用程序，试图了解每个应用程序的去向。
我遵循的步骤
- 我确信数据存储库不足。一个简单的界面 CRUD和/或复杂的查询
- 我创建了一个
IService，它实现并继承了回购协议 - 现在在wpf中我必须引用服务dll，但是wpf不仅需要服务dll，而且还需要存储库dll，因为服务层正在使用它。
我的问题是。正常吗服务不应该独立吗？
服务层应该使用它自己的模型吗？并将数据存储库模型转换为服务模型？因此，wpf将不需要引用存储库？ （但是，如果是。.不是重复的工作吗？）
解决方法
域模型
这取决于您要实现的模式：富域模型或贫血症。
一些裁判：
两个词：
- 富域模型-这是一个模型，当业务逻辑封装在您的业务对象（模型）上时。
- 贫血症域模型-当在服务层实现业务逻辑时，它是一个模型。
如果您谈论服务，那不是纯DDD，而是贫血。
福勒告诉我，贫血是一种反模式，但它经常被使用。富域模型的主要问题在于，您需要大量经验来实现正确的实现方式。
我认为您可以将实体用作域对象。
域模型存放在哪里？
如果您尝试实现域模型，则需要解决方案的组织结构。
通常它包含下一个项目：
*.Domain-用于域对象*.Application-对于您的业务逻辑，如果我们谈论贫血模型*.Dto或*.Contract-用于dto或可以在应用程序的外部范围使用的其他对象（用于服务交互，dto的等）*.Persistence-用于数据层
Dto(Contract)被放置在另一个项目中，以防重复使用在其上实现的项目。
其中*是您的项目名称。
DTO
Dto取决于您的需求。
我建议为每种目的声明dto，但是如果您不想这样做，仍然可以返回域对象（但是有人可以说这是不好的做法）。
正如我之前告诉您的，您可以将dto放置到* .Dto或* .Contract项目中
服务层和业务层
在您的*.Application
数据存储库
通常，您更喜欢在*.Domain或*.Application声明Data Repository接口，并在*.Persistence声明实现。它允许您使用界面，而不关心实现。
正常吗？服务不应该独立吗？
最佳实践是服务仅取决于您的*.Domain程序集。
服务层应该使用它自己的模型吗？并将数据存储库模型转换为服务模型？因此，wpf将不需要引用存储库？ （但如果是，..不是重复的工作吗？）
您的服务应与域模型一起使用，并在需要时返回dto。 ddd的一般想法之一是，所有操作都具有通用模型。因此，如果您可以从存储库中返回域模型，那就很好了。