在我的WPF&x2B中是否需要DDD；WCF场景？

我正在开发一个WPF应用程序，它连接到几个WCF服务（与LINQ-to-EF一起工作）

WPF是以MVVM方式设计的

对于每个WCF服务，我有以下几点：

• 服务层DLL-这包括服务接口、服务实现。服务实现只是创建BL对象并对其调用方法
• 服务BL层DLL-这包括一个管理器工厂（工厂创建UserManager、TaskManager等）。每个管理器都有一个接口+实现（用于单元测试和DI）。例如，TaskManager有“GetTask”、“CheckTaskIsValid”等。此外，BL层还有一个“Trasnlator”类，用于将数据实体转换为DTO。BL管理器方法将DTO返回到服务层

除上述内容外，所有服务BL都引用数据访问层DLL，其中包括：

• 来自MS SQL Server的带有表的EDMX文件
• 自动生成的DbContext+POCO实体
• 查询提供程序（由BL管理器类使用）。每个查询提供程序都有一个接口+实现，用于单元测试和DI目的
• DbContext工厂-接口+实现，用于单元测试和DI目的

这些服务采用CQS设计（命令查询分离，不与CQR混合），这意味着只有一个服务负责查询，另一个服务负责发送命令

我通过托管所有服务的WCF主机项目使用DI（使用AutoFac）（我实现了IInstanceProvider，以便可以向服务注入依赖项）

我没有实现自己的存储库或工作单元，因为DbContext已经是UoW和存储库

这个设计有缺陷吗

我读过很多关于DDD的帖子，我知道我的设计不是DDD

我的问题是——我的设计足够好吗？我是否需要将所有代码重构为DDD？（使用骨料和根骨料等）

---

我已经尽力提供尽可能多的设计细节，所以我希望我不会得到像“你的问题太笼统”或“需要一些例子”这样的答案。。。任何有用的信息都将不胜感激

是的，您没有DDD设计，但没有DDD并不意味着设计不好。我认为，当您的系统是可测试的，并且对于进一步的开发是灵活的，那么扩展就适合您的需求，而不是您的系统设计适合您的需求

所有其他听起来都不错，除了：

我没有实现自己的存储库或工作单元，因为 DbContext已经是UoW和存储库

不实现UoW和存储库意味着您与实体框架紧密耦合，这可能是可测试性方面的问题。但您可以用集成测试数据库来覆盖它。数据库逻辑的单元测试有时会测试自身

---

你需要DDD吗？也许当系统比进化更复杂时，你们会来到DDD和CQR。但当它对您来说足够了，易于维护和进一步开发，可测试，可扩展，当系统不脆弱时，比我想象的要容易，最好专注于业务需求

当您不提及您的领域时，我们如何建议您使用领域驱动设计？@Martijn-您能解释一下您需要我提供哪些信息吗？（我不知道“域”到底指的是什么）