DDD 公开了有界上下文、领域模型、聚合……但我经常错过业务规则的关键点。我想知道业务规则如何集成到这种方法中。这是一个例子：
假设您在一家信贷公司中有 2 个有界上下文。一项用于追偿债务，另一项用于提前退款。这些背景嵌入了真正的业务特性。从概念的角度来看，我认为这些有界上下文应该分别嵌入公共模型部分和类似的领域模型实体（3 或 4 个会计实体的图）。即使它们各自的模型嵌入了一个公共子模型（我们不计划它可以改变），适用于这些子模型的业务规则也是不同的。 DebtRecoveryService 确保规则得到正确应用，另一个 EarlyFundsService 也通过特定的会计规则执行相同的操作。
- 如果不同的业务规则适用于它们（在数学和各自的行为方面？），那么这个子模型是否应该由另一个专用的有界上下文嵌入并“服务于其他人”。
- 什么定义了聚合，它只是模型的一部分吗？
- 特定的业务规则是否定义了特定的聚合？
您是否认为聚合应该仅考虑它所代表的实体图，并由其他有界上下文“重用”？这是 CQRS 的好案例吗？
Thanks,
看起来很清楚，根据 DDD 你should当模型被不同的有界域共享时，会复制模型。
此外，服务模式鼓励不要在服务的两侧使用相同的对象。
然而。如果您使用 POCO 风格的数据对象并将业务逻辑封装在服务中，而不是经典的 OO 对象图方法，那么您本质上是在使用多种模式来保护自己免受同一问题的影响。
在这种情况下，如果该模型的领域含义随着时间的推移在有界上下文之间发生变化，那么拥有共享通用模型所带来的代码重用的好处可能会超过潜在的技术债务。
本质上，这可能发生在有界上下文中。我觉得你的问题可以归结为“我选择了正确的有界上下文吗？”这当然是主观的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
