如何确定“ DDD”解决方案在域或应用程序项目中的处理方式？

Question

我正在学习应用于.NET解决方案的DDD和以域为中心的体系结构设计。

但是，我在如何实现它方面有些挣扎。

最近我想到了一些例子：

• 将excel文件过滤/转换为另一种文件json / xml，并按照某些业务规则进行格式化，无论是控制台应用程序还是WebAPI
• 计算部署的能量或某些火车站的距离

如何确定应用程序“层”和域“层”中包含什么？

我读到

• https://softwareengineering.stackexchange.com/questions/140999/application-layer-vs-domain-layer
• https://github.com/thiagolunardi/MvcMusicStoreDDD
• https://github.com/rafaelfgx/DotNetArchitecture
• https://github.com/EduardoPires/EquinoxProject
• https://github.com/ardalis/ddd-guestbook
• https://github.com/dotnet-architecture/eShopOnWeb
• https://github.com/HudsonLima/Product-API
• https://github.com/thangchung/magazine-website
• https://github.com/gigiogodoi/Blackbird
• https://github.com/JasonGT/DDDBNE2017
• https://github.com/felipeolimpos/base-core-ddd-mvc-ef-pg-ioc-proj
• https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice

Answer 1

域层包含执行业务规则的所有代码。

它应该与技术无关（例如特定的数据库-sql，无sql-或协议-HTTP，REST）和框架无关。这意味着无论聚合是持久存储在SQL数据库还是NoSQL数据库中，其外观都是相同的，它是通过HTTP控制器或控制台应用程序调用的。

应该为pure，没有副作用。这意味着它不应执行任何I/O（从任何文件读取或写入）。它接收所有需要的数据作为方法参数。对我来说，将基础结构或应用程序层作为参数传递给Aggregate方法调用也是不好的，即使它隐藏在域interface后面，因为它可以执行I/O。

它不应依赖于其他任何层。这意味着没有其他层的imports或use（或您在编程语言中使用的任何编程语言构造）。

应用程序层是一个薄层，用于从存储库加载聚合，它在聚合上调用相应的方法，然后将聚合持久化到存储库。它基本上将域与基础结构粘合在一起。

Answer 2

在 DDD 架构中，所有业务逻辑和规则都应该在域层内。应用层负责通过访问域层来引用业务逻辑，并通过基础设施层进行数据库更新。所以很明显，如果您要添加业务规则或逻辑，它应该是域层