标签: domain-driven-design

在 DDD 项目中，我有这样的结构：

基础设施

• MyProj.Library（包含辅助方法）
• MyProj.Factory（包含 IoC 和 DI 的方法）
• MyProj.Data（包含 IUserRepository 的实现）

领域

• MyProj.Domain（包含域聚合和存储库接口，即 IUserRepository）

应用

• MyProj.WebAPI

我需要知道MyProj.Data属于基础设施层还是域层。我真的很困惑实施的存储库属于哪里。

1. 有人可以给我一个域服务的好例子吗
2. 他们应该是无状态的吗？
3. 它们相当于交易脚本吗？
4. 报告生成服务可以作为域服务调用吗？

DDD 公开了有界上下文、领域模型、聚合……但我经常错过业务规则的关键点。我想知道业务规则如何集成到这种方法中。这是一个例子：

假设您在一家信贷公司中有 2 个有界上下文。一项用于追偿债务，另一项用于提前退款。这些背景嵌入了真正的业务特性。从概念的角度来看，我认为这些有界上下文应该分别嵌入公共模型部分和类似的领域模型实体（3 或 4 个会计实体的图）。即使它们各自的模型嵌入了一个公共子模型（我们不计划它可以改变），适用于这些子模型的业务规则也是不同的。DebtRecoveryService 确保规则得到正确应用，另一个 EarlyFundsService 也使用特定的会计规则执行相同的操作。

• 如果不同的业务规则适用于它们（在数学和各自的行为方面？），那么这个子模型是否应该由另一个专用的有界上下文嵌入并“服务于其他人”。
• 什么定义了聚合，它只是模型的一部分吗？
• 特定的业务规则是否定义了特定的聚合？

您是否认为聚合应该仅考虑它所代表的实体图，并由其他有界上下文“重用”？这是 CQRS 的好案例吗？

谢谢，

我是 DDD 的初学者，我尝试用 C# 优雅地建模下一个场景：

1. 基本上只有一个名称属性和必须按特定顺序执行的项目列表的模板。

   public class Template
   {
       public string Name { get; set; }
       public List<Item> Items { get; set; }
   }
   
   public class Item
   {
       public string Name { get; set; }
       public int Order { get; set; }
   }
   

   Run Code Online (Sandbox Code Playgroud)

2. 一种称为 Profile 的类型。

   public class Profile
   {
       public string Name { get; set; }
   }
   

   Run Code Online (Sandbox Code Playgroud)

profile 类的意思是

• 我使用模板 A 来了解我拥有哪些项目以及顺序
• 如果模板 A 发生更改，那么我将使用新版本，因为我不想保留模板 A 所具有的列表的克隆。
• 如果我被删除，那么模板不会受到任何影响
• 如果我被创建，那么我需要一个模板
• 只能用我的名字来照顾我

这看起来像是聚合根是模板，其中包含项目列表和配置文件列表。但我觉得按配置文件名称搜索需要我搜索具有给定名称的配置文件的所有模板。不知何故，对于具有 CRUD 背景的人来说，这似乎要付出高昂的代价。此外，配置文件是使用模板的配置文件，并且让模板了解使用它的配置文件似乎是错误的。

你如何建模？这里的聚合根应该是什么？是不止一个吗？如果您想从 UI 中使用搜索，如何执行搜索？

给定一个ReceiptValidator接口和一个返回多个数据的GoogleReceiptValidator实现，我应该在哪里放置ReceiptValidatorResult？

由于它与ReceiptValidator相关，因此可以将其放置在 Domain Layer 中。

但是，如果另一个AppleReceiptValidator有不同的数据怎么办？ReceiptValidatorResult也应该是一个接口吗？

想象一下使用微服务的 OAuth 提供商。我们将为授权端点、令牌端点等提供微服务。

For example, every endpoint is different microservice and most endpoints will need to retrieve client by id to authenticate request. So how should I share method to get client from database, model for client and all related to it entities?

How shall I share common methods and classes between microservices?

If microservice A depends on microservice B, then I need to do communication between them over HTTP or I just can add project reference? Or maybe situation …

我是DDD(领域驱动设计)的新手,我喜欢它的很多想法.但是使用DDD,我需要花费大量时间分析域,定义实体和值对象,选择聚合并定义它们的边界等等.所以我想知道 - 它不是回归到BDUF(Big Design Up Front)吗？将DDD和敏捷放在一起有一些很好的经验吗？

我今天参加了由一位非常著名且受人尊敬的作家、讲师和软件工程、架构和设计专家主持的网络研讨会。网络研讨会的主题是“增量架构”。这位名人表示，DDD 中的实体概念与数据库中的实体概念无关。这是埃里克·埃文斯 (Eric Evans) 在他 2003 年的原著中不幸选择的术语。我对他的解释并不满意，而且我发现他的声明可能会让任何试图在设计中使用 DDD 的人感到非常困惑。

我的问题：DDD 中的实体一词究竟是什么意思？- 如果不是数据库、ORM 框架、JPA、开发框架（Spring）等中对实体的很好理解和很好定义的概念。

广泛的软件架构研究。

这是一个关于 DDD 战略设计的问题。不涉及编码。

与我的问题无关。您允许使用关于 DDD 的主题标签，这是一种设计方法，而不是一种编码方法，但您坚持提出与代码相关的问题。DDD 与编码有何关系？