我正在阅读this blog,我想知道工作人员服务是否是实现DDD解决方案内部的最佳项目类型(最接近域/模型的领域,而其中包含所有业务的领域)逻辑和用例)。
(图片是从this blog剪下来的。)
在我看来,确实是这样,并且比起以前使用默认的Web服务,这是一个更明智的选择。可悲的是,由于该功能是.NET Core 3中的新增功能,因此没有太多可靠的资料可供Google搜索以获取灵感。
我认为,可以将继承类的实例注入DbContext
到worker中,而又不会影响DDD体系结构。还是考虑到我在这里没看到?
答案 0 :(得分:0)
首先,域驱动设计从来都不是一种架构样式或模式。这是一种围绕业务领域设计系统并识别不同级别的边界的方法,例如系统和语言边界(边界上下文)和事务边界(集合)。
大多数使用DDD构建的应用程序的核心是域模型。域模型是一种旧模式,早在DDD之前就已存在。模式本身及其DDD解释共有一个重要特征-实现域模型的代码不依赖于任何基础结构。因此,它非常适合端口和适配器/六边形体系结构。
您要确切地托管域模型的位置,想要拥有哪种类型的应用程序服务(端口)和边缘层(适配器)与DDD完全正交。工作者服务,持久参与者,消息使用者,REST或gRPC端点-确实如此。
有些人将执着的演员视为代表群体的理想人选。对我来说,直接耦合到任何类型的基础架构的任何内容都不适合成为域模型的一部分。不过,很可能成为主机和应用程序层。