认识达内从这里开始

领域驱动设计随着互联网的不断发展而被越来越多的程序员掌握，今天我们就通过案例分析来简单了解一下，领域驱动设计概念与设计模型分享。

1.微服务划分

从广义上讲，领域即是一个组织所做的事情以及其中包含的一切。每个组织都有它自己的业务范围和做事方式，这个业务范围以及在其中所进行的活动便是领域。

DDD的子域和限界上下文的概念，可以很好地跟微服务架构中的服务进行匹配。而且，微服务架构中的自治化团队负责服务开发的概念，也与DDD中每个领域模型都由一个独立团队负责开发的概念吻合。DDD倡导按业务领域来划分系统，微服务架构更强调从业务维度去做分治来应对系统复杂度，跳过业务架构设计出来的架构关注点不在业务响应上，可能就是个大泥球，在面临需求迭代或响应市场变化时就很痛苦。

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致;在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

以电商的资源订购系统为例，业务用例场景包括查看资源，购买资源，查询用户已购资源等。

领域驱动为每一个子域定义单独的领域模型，子域是领域的一部分，从业务的角度分析我们需要覆盖的业务用例场景，以高内聚低耦合的思想，结合单一职责原则(SRP)和闭包原则(CCP)，从业务领域的角度，划分出用户管理子域，资源管理子域，订单子域和支付子域共四个子域。

每个子域对应一个限界上下文。限界上下文是一种概念上的边界，领域模型便工作于其中，每个限界上下文都有自己的通用语言。限界上下文使得你在领域模型周围加上了一个显式的、清晰的边界。当然，限界上下文不仅仅包含领域模型。当使用微服务架构时，每个限界上下文对应一个微服务。

2.领域模型

聚合是一个边界内领域对象的集群，可以将其视为一个单元，它由根实体和可能的一个或多个其他实体和值对象组成。聚合将领域模型分解为块，每个聚合都可以作为一个单元进行处理。

聚合根是聚合中可以由外部类引用的部分，客户端只能通过调用聚合根上的方法来更新聚合。

聚合代表了一致的边界，对于一个设计良好的聚合来说，无论由于何种业务需求而发生改变，在单个事务中，聚合中的所有不变条件都是一致的。聚合的一个很重要的经验设计原则是，一个事务中只修改一个聚合实例。更新聚合时需要更新整个聚合而不是聚合中的一部分，否则容易产生一致性问题。

比如A和B同时在网上购买东西，使用同一张订单，同时意识到自己购买的东西超过预算，此时A减少点心数量，B减少面包数量，两个消费者并发执行事务，那么订单总额可能会低于低订单限额要求，但对于一个消费者来说是满足低限额要求的。所以应该站在聚合根的角度执行更新操作，这会强制执行一致性业务规则。

另外，我们不应该设计过大的聚合，处理大聚合构成的"巨无霸"对象时，容易出现不同用例同时需要修改其中的某个部分，因为聚合设计时考虑的一致性约束是对整个聚合产生作用的，所以对聚合的修改会造成对聚合整体的变更，如果采用乐观并发，这样就容易产生某些用例会被拒绝的场景，而且还会影响系统的性能和可伸缩性。

使用大聚合时，往往为了完成一项基本操作，需要将成百上千个对象一同加载到内存中，造成资源的浪费。所以应尽量采用小聚合，一方面使用根实体来表示聚合，其中只包含小数量的属性或值类型属性，这里的小数量表示所需的小属性集合，不多也不少。必须与其他属性保持一致的属性是所需的属性。

在聚合中，如果你认为有些被包含部分应该建模成一个实体，此时，思考下这个部分是否会随着时间而改变，或者该部分是否能被全部替换。如果可以全部替换，那么可以建模成值对象，而非实体。因为值对象本身是不可变的，只能进行全部替换，使用起来更安全，所以，一般情况下优先使用值对象。很多情况下，许多建模成实体的概念都可以重构成值对象。小聚合还有助于事务的成功执行，即它可以减少事务提交冲突，这样不仅可以提升系统的性能和可伸缩性，另外系统的可用性也得到了增强。

另外聚合直接的引用通过标识实现，而不是通过对象引用，这样不仅减少聚合的使用空间，更重要的是可以实现聚合直接的松耦合。如果聚合是另一个服务的一部分，则不会出现跨服务的对象引用问题，当然在聚合内部对象之间是可以相互引用的。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。