内容简介：来自Kamil Toszek一篇DCI与DDD结合的文章：我正在实践领域驱动设计方法，它有一些很好的部分比如有界上下文（模块分离很好 - 每个模块代表上下文边界），还有一些 - 对我来说 - 不是那么好的部分：领域富血模型。DDD说实体的功能应该是该实体的一部分，这导致具有许多功能的类在不同的上下文中使用，打破单一责任规则。例如，如果我是一个实体：一个“Person”，我想要纳税，那么"Person"会获得payTaxes功能,现在，如果我想和儿子一起玩，那么"Person"会得到playWithSon函
来自Kamil Toszek一篇DCI与DDD结合的文章：
我正在实践领域驱动设计方法，它有一些很好的部分比如有界上下文（模块分离很好 - 每个模块代表上下文边界），还有一些 - 对我来说 - 不是那么好的部分：领域富血模型。
DDD说实体的功能应该是该实体的一部分，这导致具有许多功能的类在不同的上下文中使用，打破单一责任规则。例如，如果我是一个实体：一个“Person”，我想要纳税，那么"Person"会获得payTaxes功能,现在，如果我想和儿子一起玩，那么"Person"会得到playWithSon函数，Person类将具有许多在上下文方面彼此无关的函数。
DCI代表数据，上下文，交互，这个想法是应用程序可以在数据（软件是什么）和功能（软件做什么）之间分开，DCI表示该模型应该是贫血的，但您可以将角色应用到您的模型，从而为你的模型（可切换）这个角色具有的功能。如果一个Person类只有基本属性，将TaxPayerRole这个角色作为构造函数的入参来接受，并为在某些上下文使用场景中提供TaxPayerRole的功能（用例）；也可以将DadRole作为入参接受。
正如Robert Martin写道：“您的架构会大声喊出它的功能，而不是依赖它正在使用的框架”。
以上所述就是小编给大家介绍的《DCI与DDD》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
