我正在学习适用于 .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://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice
最佳答案
域层 包含执行业务规则的所有代码。
它应该是技术不可知的(比如特定的数据库 - sql,没有 sql - 或协议(protocol) - HTTP,REST)和框架不可知。这意味着无论聚合是持久保存在 SQL 数据库还是 NoSQL 数据库中,无论是从 HTTP Controller 还是从控制台应用程序调用,它看起来都是一样的。
应该是pure ,没有副作用。这意味着它不应执行任何 I/O
(从任何文件读取或写入)。它接收它需要的所有数据作为方法参数。对我来说,将基础架构或应用程序层作为参数传递给聚合方法调用也很糟糕,即使它隐藏在域 interface
后面,因为它可以执行 I/O
.
它不应该依赖于任何其他层。这意味着不会从其他层(或您在编程语言中使用的任何编程语言构造)导入
或使用
。
应用层是一个薄层,它从存储库加载聚合,它调用聚合上的相应方法,然后将聚合持久化到存储库。它基本上将领域与基础设施粘合在一起。
关于c# - 如何确定 "DDD"解决方案中域或应用程序项目中的内容?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53122006/