作者:知一杂谈出处:https://noogel.xyz/2021/01/15/1.html领域驱动设计中界说了超多的观点，如果不多找几篇资料综合的去看，正确的明白比力难题，下面搜集整理了大部门的领域驱动中的观点，并加以明白形貌。战略设计与战术设计战略设计主要从业务视角出发，建设业务领域模型，划分领域界限，建设通用语言的限界上下文，限界上下文可以作为微服务设计的参考界限。它是从高层事业来绅士我们的软件系统。从战略设计角度来看，一套基础的电商业务应该包罗如下领域，支付域、生意业务域、商品域、库存域、履约域。

差别领域之间通过界线上下文来划分界限。战术设计则从技术视角出发，偏重于领域模型的技术实现，完成软件开发和落地，包罗：聚合根、实体、值工具、领域服务、应用服务和资源库等代码逻辑的设计和实现。它主要关注的是技术层面的实施，也是对我们法式员最实在的地方。战术设计的详细落地案例在后面的内容中会解说。

领域 & 子领域DDD 的领域就是这个界限内要解决的业务问题域。既然领域是用来限定业务界限和规模的，那么就会有巨细之分，领域越大，业务规模就越大，反之则相反。领域可以进一步划分为子领域。

我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务规模。焦点域 & 通用域 & 支撑域在领域不停划分的历程中，领域会细分为差别的子域，子域可以凭据自身重要性和功效属性划分为三类子域，它们划分是：焦点域、通用域和支撑域。决议产物和公司焦点竞争力的子域是焦点域，它是业务乐成的主要因素和公司的焦点竞争力。

没有太多个性化的诉求，同时被多个子域使用的通用功效子域是通用域。另有一种功效子域是必须的，但既不包罗决议产物和公司焦点竞争力的功效，也不包罗通用功效的子域，它就是支撑域。基于以上观点界说，对订单域举行如下的拆分，其中生意业务子域和算价子域是最关键的焦点子域，限购子域、交付子域、报表子域、会员订阅子域是支撑子域，消息子域为相同各个子域的桥梁分类为通用子域。

注意这里的曲线只是用来区分差别子域类型，不是界线上下文。事件风暴事件风暴是一项团队运动，领域专家与项目团队通过头脑风暴的形式，枚举出领域中所有的领域事件，整合之后形成最终的领域事件荟萃，然后对每一个事件，标注出导致该事件的下令，再为每一个事件标注出下令提倡方的角色。

下令可以是用户提倡，也可以是第三方系统挪用或者定时器触发等，最后对事件举行分类，整理出实体、聚合、聚合根以及限界上下文。而事件风暴正是 DDD 战略设计中经常使用的一种方法，它可以快速分析和剖析庞大的业务领域，完成领域建模。

通用语言 & 界线上下文在 DDD 领域建模和系统建设历程中，有许多的到场者，包罗领域专家、产物司理、项目司理、架构师、开发司理和测试司理等。对同样的领域知识，差别的到场角色可能会有差别的明白，那大家交流起来就会有障碍，怎么办呢？因此，在 DDD 中就泛起了“通用语言”和“限界上下文”这两个重要的观点。

这两者相辅相成，通用语言界说上下文寄义，限界上下文则界说领域界限，以确保每个上下文寄义在它特定的界限内都具有唯一的寄义，领域模型则存在于这个界限之内。通用语言团队交流告竣共识的能够明确简朴清晰的形貌业务规则和业务寄义的语言就是通用语言。

解决各岗位的相同障碍问题，促进差别岗位的和互助，确保业务需求的正确表达。通用语言贯串于整个设计历程，基于通用语言可以开发出可读性更好的代码，能准确的把业务需求转化为代码。界线上下文用来封装通用语言和领域工具，提供上下文情况，保证在领域之内的一些术语、业务相关工具等（通用语言）有一个确切的寄义，没有二义性。这个界限界说了模型的适用规模，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。

栗子说明在商品域，商品实体则对应着一个详细的 SKU 商品，包罗着标题和金额，如现在的课程、会员服务。在订单域中的商品实体并不等同域商品域中的实体，好比可以将优惠券做成可以被售卖的商品，coupon_no 就是 product_key，具有 non-consumable 属性；或者将付费咨询的用户服务打包成商品售卖，那么 member_id 就能映射成 producer_key，而且觉有 consumable 属性。界线上下文就是区分差别领域下的领域工具，划定了领域工具寄义的界限。

在订单域中，商品实体默认可以是商品系统 SKU，也可以是优惠券和用户服务等。上下文映射图上下文映射图就通过绘图的方式展示N（N>=2）个上下文之间的映射关系。ACL表现防腐层，OHS表现开放主机服务，PL表现公布语言，U代表上游，D代表下游。领域服务你是否遇到过这样的问题：想建模一个领域观点，把它放在实体上不合适，把它放在值工具上也不合适，然后你冥思苦想着自己的建模方式是不是出了问题。

恭喜你，祝贺你，你的建模手法完全没有问题，只是你还没有接触到领域服务（Domain Service）这个观点，因为领域服务原来就是来处置惩罚这种场景的。好比，要对客户端类型和版本举行判断是否支持某一项功效，我们可以建立一个 ClientVersionService 来卖力。值得一提的是，领域服务和上文中提到的应用服务是差别的，领域服务是领域模型的一部门，而应用服务不是。应用服务是领域服务的客户，它将领域模型酿成对外界可用的软件系统。

领域事件在DDD中，领域事件便可以用于处置惩罚上述问题，此时最终一致性取代了事务一致性，通过领域事件的方式到达各个组件之间的数据一致性。领域事件的命名遵循英语中的“名词+动词已往分词”花样，即表现的是先前发生过的一件事情。好比，购置者提交商品订单之后公布 OrderCreated 事件，用户支付 TradePaid 事件。

需要注意的是，既然是领域事件，他们便应该从领域模型中公布。领域事件的最终吸收者可以是本限界上下文中的组件，也可以是另一个限界上下文。领域事件的分外利益在于它可以记载发生在软件系统中所有的重要修改，这样可以很好地支持法式调试和商业智能化。

另外，在CQRS架构的软件系统中，领域事件还用于写模型和读模型之间的数据同步。再进一步生长，事件驱动架构可以演酿成事件源（Event Sourcing），即对聚合的获取并不是通过加载数据库中的瞬时状态，而是通过重放发生在聚合生命周期中的所有领域事件完成。实体 & 值工具 & 聚合 & 聚合根实体 & 值工具实体和值工具是组成领域模型的基础单元。

在 DDD 中有这样一类工具，它们拥有唯一标识符，且标识符在历经种种状态变换后仍能保持一致。对这些工具而言，重要的不是其属性，而是其延续性和标识，工具的延续性和标识会跨越甚至超出软件的生命周期。我们把这样的工具称为实体。

通过工具属性值来识此外工具，它将多个相关属性组合为一个观点整体。在 DDD 中用来形貌领域的特定方面，而且是一个没有标识符的工具，叫作值工具。值工具本质就是一个荟萃，可以保证属性归类的清晰和观点的完整性。

举例说明消费者实体原本包罗：ID、昵称、注册手机号、姓名以及人员所在的省、市、县和街道等属性。这样显示地址相关的属性就很琐屑了对差池？现在，我们可以将“省、市、县和街道等属性”拿出来组成一个“地址属性荟萃”，这个荟萃就是值工具了。聚合 & 聚合根聚合是业务和逻辑精密关联的实体和值工具组合而成，聚合是数据修改和持久化的基本单元，一个聚合对应一个数据的持久化。

聚合在DDD分层架构中属于领域层，领域层包罗了多个聚合，配合实现焦点业务逻辑，聚合内的实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。如果把聚合比作组织，聚合根则是组织的卖力人，聚合根也叫做根实体，它不仅仅是实体，还是实体的治理者。

聚合之间通过聚合根关联引用，如果需要会见其他聚合的实体，先会见聚合根，再导航到聚合内部的实体。即外部工具不能直接会见聚合内的实体。

举例说明上图说明聚合与聚合根的关系，生意业务聚合有一个唯一的聚合根生意业务单，生意业务单组织了消费者实体、商品实体、商铺实体、优惠券实体同时消费金额之工具。下面详细对比说明下：聚合的特点：高内聚、低耦合，它是领域模型中最底层的界限，可以作为拆分微服务的最小单元，但我不建议你对微服务过分拆分。

但在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频公布和极致的弹性伸缩能力。一个微服务可以包罗多个聚合，聚合之间的界限是微服务内天然的逻辑界限。有了这个逻辑界限，在微服务架构演进时就可以以聚合为单元举行拆分和组合了，微服务的架构演进也就不再是一件难事了。聚合根的特点：聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。

一个聚合只有一个聚合根，聚合根在聚合内对实体和值工具接纳直接工具引用的方式举行组织和协调，聚合根与聚合根之间通过 ID 关联的方式实现聚合之间的协同。实体的特点：有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。

状态可变，它依附于聚合根，其生命周期由聚合根治理。实体一般会持久化，但与数据库持久化工具纷歧定是一对一的关系。实体可以引用聚合内的聚合根、实体和值工具。

值工具的特点：无 ID，不行变，无生命周期，用完即扔。值工具之间通过属性值判断相等性。

它的焦点本质是值，是一组观点完整的属性组成的荟萃，用于形貌实体的状态和特征。值工具只管只引用值工具。防腐层通过在遗留系统和现代系统之间使用防腐层来隔离它们。该层转换两个系统之间的通信，允许遗留系统保持稳定，同时可以制止损害现代应用法式的设计和技术方法。

现代应用与防腐层之间的通信始终使用应用法式的数据模型和架构。从防腐层到遗留系统的挪用都切合该系统的数据模型或方法。防腐层包罗两个系统之间转换所需的所有逻辑。

该层可以作为应用法式中的组件或作为独立服务来实现。贫血模型贫血模型就是模型工具之间存在完整的关联(可能存在多余的关联)，可是工具除了get和set方外外险些就没有其它的方 法，整个工具充当的就是一个数据容器，用C语言的话来说就是一个结构体，所有的业务方法都在一个无状态的Service类中实现，Service类仅仅包 含一些行为。贫血模型的优点是很显着的：被许多法式员所掌握，许多课本接纳的是这种模型，对于初学者，这种模型很自然，甚至被许多人认为是java中最正统的模型。

它很是简朴，对于并不庞大的业务(转帐业务)，它事情得很好，开提倡来很是迅速。它似乎也不需要对领域的充实相识，只要给出要实现功效的每一个步骤，就能实现它。

事务界限相当清楚，一般来说service的每个方法都可以看成一个事务，因为通常Service的每个方法对应着一个用例。（在这个例子中我使用了facade作为事务界限，后面我要讲这个是多余的)其缺点为也是很显着的：所有的业务都在service中处置惩罚，当业越来越庞大时，service会变得越来越庞大，最终难以明白和维护。将所有的业务放在无状态的service中实际上是一个历程化的设计，它在组织庞大的业务存在天然的劣势，随着业务的庞大，业务会在service中多个方法间重复。当添加一个新的UI时，许多业务逻辑得重新写。

例如，当要提供Web Service的接口时，原先为Web界面提供的service就很难重用，导致重复的业务逻辑（在贫血模型的分层图中可以看得更清楚），如何保持业务逻辑一致是很大的挑战。领域模型领域模型是对领域内的观点类或现实世界中工具的可视化表现。

又称观点模型、领域工具模型、分析工具模型。它专注于分析问题领域自己，掘客重要的业务领域观点，并建设业务领域观点之间的关系。领域驱动模型，与贫血模型相反，领域模型要负担关键业务逻辑，业务逻辑在多个领域工具之间分配，而Service只是完成一些不适合放在模型中的业务逻辑，它是很是薄的一层，它指挥多个模型工具来完成业务功效。

其优点是：领域模型接纳OO设计，通过将职责分配到相应的模型工具或Service，可以很好的组织业务逻辑，当业务变得庞大时，领域模型显出庞大的优势。当需要多个UI接口时，领域模型可以重用，而且业务逻辑只在领域层中泛起，这使得很容易对多个UI接口保持业务逻辑的一致(从领域模型的分层图可以看得更清楚)。其缺点是：对法式员的要求较高，初学者对这种将职责分配到多个协作工具中的方式感应极不适应。

领域驱动建模要求对领域模型完整而透彻的相识，只给出一个用例的实现步骤是无法获得领域模型的，这需要和领域专家的充实讨论。错误的领域模型对项目的危害很是之大，而实现一个好的领域模型很是难题。对于简朴的软件，使用领域模型，显得有些杀鸡用牛刀了。

开放主机服务该模式可以通过REST实现。通常来讲，我们可以将开放主机服务看作是远程历程挪用（RPC）的API。同时，也可以通过消息机制实现。参考https://www.cnblogs.com/snidget/p/12995676.htmlhttps://zhuanlan.zhihu.com/p/130945830https://blog.csdn.net/itfly8/article/details/109554847https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.htmlhttps://iambowen.gitbooks.io/cloud-design-pattern/content/patterns/anti-corruption-layer.html作者:知一杂谈出处:https://noogel.xyz/2021/01/15/1.html。

本文来源：亚博2022手机登录网址-www.kelon-bj.com