4.模型驱动设计

4. 模型驱动设计

领域即所处理问题的区域，领域模型是问题域的抽象，用来描述领域中复杂逻辑和策略以便解决业务逻辑问题，而不是追求最大程度上反映现实情况，领域模型需要清晰明确并拜托技术的复杂性，这样业务和开发人员就能够基于领域模型的设计来协作，但是简单的场景或者非核心域没有必要使用模型驱动设计。

领域和领域模型.png 领域模型的生成和作用.png

如何创造有效的领域模型

1. 不要过度关注现实世界。

   领域模型要聚焦满足业务场景的用例建模，理解可能会发生变化以及非常复杂的部分，是对解决特定业务用例的问题域的说明，不能完全的映射现实世界。

比如当前的业务中只能使用一种支付方式，现实世界付款的时候有可能存在多种支付方式，不必纠结现实场景，模型翻译当前业务就行。

2. 仅根据相关性建模

   要根据系统的不变条件和规则定义定义联系，时刻牢记是为了创建满足业务用例，而不是反映现实，面对新的场景持续质疑创建的模型，并与领域专家交流移除不相关性。

比如创建电商领域价格计算模型，计算的主体是商品是不变的、优惠的来源和限制策略是变化的（商家、 优惠券、支付方式）

3. 十分清楚专业术语

   开发人员编码不是主要的，解决问题是主要的，使用通用语言交流沟通，确保精准理解领域问题。

4. 理解领域模型是暂时有效

   领域模型是反映当前已经存在的业务逻辑，未来的业务变化导致当前模型不相关时要乐于废弃重新创建，所以不必痴迷完美模型。

比如当前购物车可能是基于用户id+店铺id为唯一索引的，一个用户只能在一个店铺选购商品并下单，但是后续如果允许多家店铺下单，这个模型可能就需要调整，相关的变动涉及购物车优惠计算、以及后续的订单创建。

5. 谨慎使用抽象

   • 在高层级使用抽象，阅读者能够快速领会领域的概念而不必钻研代码来理解细节。

   • 在太低层级使用抽象，会在重构模型或者处理新场景时造成大量冲突。

   • 基于行为而不是基于实现进行抽象。

比如对于一个交易系统来说，可能支持很多交易模型，比如到店、外卖、自提等等，我们可以对交易中存在的行为创建一个接口包含Create、Cancel、Refund、Pay，不同的业务模型有对用的实现，这样别人很容易理解交易中行为，在维护不同业务模式代码的时候直接找对应实现就可以了。

6. 善于尝试、尽早的在代码中实现，发现受限信息。