我的WPF + WCF场景中是否需要DDD？

Question

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

WPF以MVVM方式设计。

对于每个WCF服务，我都有以下内容：

• 服务层DLL - 这包括服务接口，服务实现。服务实现只是创建BL对象并调用它们的方法
• 服务BL Layer DLL - 这包括经理工厂（工厂创建 UserManager ， TaskManager 等）。每个经理都有一个接口+实现（用于单元测试和DI）。例如 - TaskManager 具有'GetTasks'，'CheckTaskIsValid'等。此外，BL Layer有一个'Trasnlator'类，可以从 Data-Entity 转换为 DTO 。 BL管理器方法将DTO返回到服务层。

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

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

服务采用CQS设计（Command-Query-Seperation，不与CQRS混合使用），这意味着只有一个服务负责查询，一个服务负责发送命令。

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

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

这种设计有缺陷吗？

我已经阅读了很多关于DDD的帖子，我知道我的设计不是 DDD。

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

我试图提供尽可能详细的设计，所以我希望我不会得到像'你的问题太笼统'或'需要一些例子'这样的答案...任何有用的信息都会非常多赞赏！

Answer 1

是的，你没有DDD设计，但不是-DDD并不意味着糟糕的设计。我认为，当您的系统可测试且灵活用于进一步开发时，可以根据您的需求进行扩展，而不是根据您的需求进行良好的系统设计。

所有其他声音都很好，除了：

  

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

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

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