公司做网站的,网页加速器安卓,办公室装修一般多少钱一个平方,公司要做seo本文作者为长沙.NET社区开发者微笑刺客#xff0c;转载已获得作者授权。前言什么是领域#xff0c;我习惯描述的是制药领域、环境领域、建筑领域、金融领域等#xff0c;而在领域内#xff0c;各种业务规则、业务知识盛行#xff0c;如何有效的把控规则的变化#xff0c;… 本文作者为长沙.NET社区开发者微笑刺客转载已获得作者授权。前言什么是领域我习惯描述的是制药领域、环境领域、建筑领域、金融领域等而在领域内各种业务规则、业务知识盛行如何有效的把控规则的变化应对复杂知识有一个很关键的四字词语分而治之。分治法在很多场景下体现了其强大的作用力。领域本身很大那就拆分得到更小的领域也即子域如同递归调用一般将一个复杂问题拆分单独求解而最终将解汇总得到复杂问题解。怎么拆拆成怎么样合适依据什么拆这些在领域驱动设计中有了一套答案虽然领域驱动设计不是银弹但可以说的上是一套极好的系统方法论或称为架构设计的方法论。领域驱动设计常以战略设计与战术设计来将整个领域展现的淋漓尽致其作用范围既面向业务也面向技术。从战略角度(个人更喜欢称其为上帝视角)去规划系统、划分领域。而从战术角度则从技术层面来指导我们该如何去设计。战略设计战略设计主要从高层俯视(上帝视角)我们的软件系统就如同玩即时战略游戏般可以一览地图全貌以此来决定我们是要进攻还是防守哪个方向同样在软件中我们也可以以此来划分领域确定权重方向。统一语言提炼领域知识怎么个提炼法千万条罗马路各有各的看家本领。像事件风暴方法用例分析方法用户故事甚至是开大会各种讨论会等最终目的都是提炼出领域知识而提炼过程中达成描述上的一致性包括系统目标、系统范围及系统所具有的功能。这不是领域驱动设计所独有的但却是软件开发中所必须的为领域专家、业务分析人员、编码人员和测试人员等团队所有成员交流时构建统一频道。领域/子域领域拆分对于领域这个概念习惯性会想到制药领域、环境领域、金融领域等这些概念而领域本身所描述的是范围是如同现实世界般的复杂无边际。借助分治法将问题逐级细分来降低业务和技术复杂度将这复杂的世界划分出清晰的边界来反过来控制着划分后不那么复杂的世界也既领域拆分出细化后的子领域。子域划分在实际解决问题时我们也习惯将问题拆分而怎么拆基于什么原则拆可能会依据相关性权重甚至分类原则等对于系统而言会从架构方面考虑基础设施考虑等在领域驱动设计中更偏向基于业务拆分降低业务复杂度也分离技术实现的复杂度依照业务拆分后的子领域本身存在权重上的差异依照重要性和功能划分为三类投资占比也就有所不同。核心域其所体现的是核心服务是代表着产品的核心竞争力。支撑域其所体现的是支撑服务没它不行但又达不到核心的价值围绕着产品内部所需要但又不能单独变更为第三方服务即它不是一个通用的服务。通用域其所体现的中间件服务或第三方服务。本身可以通过现有的解决方案集成来完成的服务。限界上下文深入到一个子域中又是一片小天地在这天地中却又还是存在着因语义与语境上的差异让一些概念在这子域中显得额外尴尬。在一个领域 / 子域中我们会创建一个概念上的领域边界在这个边界中任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。其本质上是限界上下文引用到张逸老师的一句话上下文Context其实是动态的业务流程被边界Bounded静态切分的产物。对于子域与上下文间的关系看到很多书籍或是文章中所描述的都不一样这块的争论也没有一个最终答案个人更倾向于子域中划分上下文从拆分角度来讲这样理解更加简单。上下文识别对于上下文的识别没有可遵循的标准可走从不同的角度切入将会识别到不同的上下文可从张逸老师的领域驱动设计实践中窥之一二以业务复杂度、管理复杂度和技术复杂度出发面对这三个角度去依次分析从业务视角、工作视角、应用视角去识别进而识别出准确的上下文通过不断的分析斟酌考虑逐渐识别出符合当前预期的上下文如在实际操作环节发觉当前上下文的设计显得不那么合理还可再进行变动、拆分上下文。但需注意的一个是我们识别上下文的目的是什么是为了控制上下文准确的说是为了控制上下文的边界、大小是为了保住我们所守护的上下文不会因过度成长变大而奔溃亦或因上下文过度缩减而失去价值保证上下文内一切的稳定上下文与上下文间交互的可用性也或者是当我们退出上下文时交付出来的上下文是非常可观的而不是一个烂摊子。上下文映射规划了这么多限界上下文该如何穿针引线将这些上下文串起来便是一个问题了用例场景的完整实现往往是由多个上下文的协作完成的怎么去组织这些上下文领域驱动设计提到的几种方式及软件工程中常用模式。合作关系一荣俱荣一损俱损。共享内核上下文间共享领域实体。客户方-供应方下游客户依赖于上游供应方。遵奉者下游客户顺应上游供应方。各行其道没有关系的关系相互隔离。防腐层在下游上下文与上游间增加一道屏障以此来隔绝与上游的直接交互保护下游。开放主机服务在上游与下游上下文间增加一道协议以此来规范下游对上游的集成。已发布语言发布方上下文发布一份包含丰富文档的信息交换语言消费方上下文翻译并使用。这些模式其本质是为了协作为了满足用例场景下对多个限界上下文的调用通过上下文映射图可以清楚知晓运行逻辑。为了实现上下文映射简单讲就是如何将两个上下文连贯起来常借助的方式是诸如 RPC、HTTP、消息队列等依照上下文间映射类型挑选一件趁手的工具。分层架构我们通常喜欢对各种事情归纳总结如文章的层次分明如建筑结构高低有序、疏密有致给人一种各处所关注的信息视角不同而组合起来显得如此美妙。软件中同样运用着分层来隔离关注点以此来隔离每层的演进速率。当我们考虑限界上下文时不仅需要去考虑其内部的领域设计还得从其应用边界本身考虑限界上下文是属于架构设计层次主要针对的是后端架构层次的垂直切分按照经典 DDD 的分层结构来看共分为如下四层User Interface 为用户界面层向用户展示信息和传入用户命令。这里指的用户不单单只使用用户界面的人也可能是外部系统诸如用例中的参与者。Application 为应用层用来协调应用的活动不包含业务逻辑通过编排领域模型包括领域对象及领域服务使它们互相协作。不保留业务对象的状态但它保有应用任务的进度状态。Domain 为领域层负责表达业务概念业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心领域模型位于这一层。Infrastructure 为基础实施层提供公共的基础设施组件如持久化机制、消息管道的读取写入、文件服务的读取写入、调用邮件服务、对外部系统的调用等等。值得注意的是给定的分层方式仅仅是逻辑上的分层而对于实际的物理分层却又有所不同但遵守一个前提为好即限界上下文的边界高于分层的边界。诸如如下两种开发中常见的代码组织方式都可见到。一种是基于技术分层而另一种更偏向基于业务分层。方式一- application- productcontext- ordercontext- ...
- domain- productcontext- ordercontext- ...
- infrastructure- productcontext- ordercontext- ...
方式二- productcontext- application- domain- infrastructure
- ordercontext- application- domain- infrastructure
具体采用哪种方式并没有强制要求无论代码组织结构是否表达了层的概念都需要充分理解分层的意义并使得整个代码结构在架构上要吻合分层架构的理念。战术设计相比于战略设计的怎么规划战术设计更侧重于怎么执行详细的设计和编码。聚合在认识聚合前我们得对类再次回顾类是作为我们开发中的最小单元一切以类构建而在上下文的视角中聚合成了最小概念包装了一组高度相关的对象上下文内以聚合为最小单元以此来保证聚合边界。又将分而治之的思想融入到了限界上下文的内部。聚合本身是由一个或多个实体及值对象组成其中一个实体作为聚合根。管理着内部关联的实体与值对象对外代表着聚合外部来访者仅可通过聚合根进行访问。对于聚合图的画法或许因人而异我更加倾向于用矩形代表实体椭圆代表值对象用 UML 类图中的组合-聚合箭头来表示其双方间的关系。需要注意的是此处的聚合不要与 UML 类图中的聚合等同起来两者含义并不相同。实体对于实体来讲这个概念对于我们并不陌生拥有者唯一的身份标识符内含属性作为该实体的静态特征作为聚合所拥有的领域知识拥有着与自身相关的领域行为。值对象对于值对象我倾向于将它理解为基础类型之延伸既能封装基础类型又能约束内部属性间关系还能拥有着自身的领域行为而与实体的区别是没有唯一身份标识尽管带来了持久化的一些问题但还是存在解决方案。以 DateTime 理解值对象最好不过了DateTime 内部的自身约束保证了每一次变动的 DateTime 都是最新的当我们想在 2 月 28 日加 1这便要依靠 DateTime 中的行为去约束内部的属性。聚合划分经统一语言与业务分析阶段借助一系列如事件风暴、用例分析法、名次动词法、四色建模法等活动后获得了一系列相关联的对象。或可形成一张庞大的对象关联图。如不考虑聚合的划分我们依照以往的思路便是创建一大堆表运用三范式或是依靠程序去保证数据的一致性不运用主外键。然后疯狂撸码CRUD 好不快活。而随着业务的逐渐扩张这当初的想法已有点吃力了如同树苗逐渐成长枝叶也逐渐增多。借助枝干我们可以分清叶子的归属而对象网中呢变得错综复杂了也就隐约有了大泥球的征兆。借助划分聚合的一些方法将其规整化。将原有复杂的对象图拆分成可控制的小型对象图。保持单一导航方向解除双向依赖保持依赖简单。保持聚合设计的小巧聚合内的业务规则一致性通过聚合标识符引用其他聚合聚合与协作聚合间因业务场景、进程边界等因素影响可依照场景使用强一致性或是最终一致性。如上的对象图依照关系的强弱关系的主与次进行了聚合划分或许得出的部分聚合存在不合理处可再调整其边界。聚合协作聚合与协作聚合之间依照聚合根实体的唯一标识符进行关联而不是通过依靠协作聚合的引用实例来完成。保持这个原则有助于保持聚合之间的边界并避免加载不必要的对象。如我们常习惯上将关联的集合对象写入到类中然后在仓储使用时通过 EF 加载导航属性以此方便直接加载关联聚合数据。//一个聚合内建议用
public class Order : AggregateRoot
{public virtual ICollectionOrderItem OrdrItems { get; set; }//...
}
_orderRepository.Include(ee.OrderItems).FirstOrDefault();
如 Order 和 OrderItem当我们考虑将其作为一个聚合时这么使用是可以的但是不能说跨聚合也这么用着如 Enterprise 和 Order划分时我们更加倾向于划分为两个聚合遵循保持聚合原则中引用聚合根的 Id 这一原则这将改善聚合的边界使其更加清晰控制更加妥当。//多聚合间不建议这么用
public class Order : AggregateRoot
{//遵循聚合原则引用 Enterprice 聚合根 Id,而不是实例public int EnterpriceId {get; set;}//public virtual Enterprice Enterprice { get; set; }//...
}
考虑到多聚合的协作便要了解下聚合的首要原则即在一次事务中只能更改一个聚合的状态因此当涉及到多个聚合协作时如创建订单完毕需要往库存中某一商品数量减少时订单本身一般会有商品聚合的标识借助这个标识通过领域事件或是集成事件方式事件接收方将相关联的库存聚合调用起来以此达到多个聚合间的协作。又或者考虑到需要调用商品的信息以使得当前订单中商品信息更加丰富可通过防腐层调用商品所在上下文远程服务或是应用服务最终本质上是调用商品聚合中的信息丰富到订单中也使得多个聚合完成协作。应用服务作为限界上下文对外的门户也即是外观模式的体现。通过用例分析识别出来的用例在此处一一对应存在着对外提供统一接口以此满足完整用例场景所需的功能。在应用服务内部通过编排领域模型对象来完成用例的功能自身并不包含领域逻辑但包含着应用逻辑。可借鉴整洁架构的经典图例来看应用层本身的职责所在Use Case(用例层)-Application Business Rules虽然是依靠着领域模型对象才完成的具体是编排领域模型对象所具有的领域行为却也说明了应用服务承担着的是用例的职责。需要注意的是应用服务的职责不仅限于编排领域模型对象还需要控制着横切关注点如验证、日志、事物等的管理。[UnitOfWork]
[Authorize(PermissionNames.PartType_Create)]
public async Task CreatePartType(CreatePartTypeDto input)
{await _validatingPartTypeManager.CheckUniqueName(input.Name, input.Category);var partType PartType.Create(input.Name, input.Description).SetCategory(input.Category).SetFactory(input.FactoryName);await _partTypeRepository.InsertAsync(partType);await _appNotifier.NewPartTypeAsync();
}
如上事务、认证、请求参数校验(Dto 内)协调领域模型对象和基础设施服务这是应用服务的职责当然也不仅限于这些职责。领域服务当我们考虑领域逻辑时首先想到的应该是实体与值对象中具有的领域逻辑而有些场景下实体与值对象无法承载这些领域行为如对多个领域对象作为输入进行计算并产出一个值对象又或是需要将操作成集合化的聚合如在 Supplier 下需要将所有 Order 中的单价汇总而本身 Supplier 和 Order 是为两个聚合若考虑借助 Order 去完成该业务操作不太妥当在此场景下可通过领域服务来承载着这些领域行为。领域服务存在如下特征执行一个显著的业务操作过程对领域对象进行转换需要使用多个聚合内的实体和值对象编排业务逻辑领域行为需要访问外部资源虽说领域服务能够承载领域逻辑却不能说将所有的领域逻辑都往里塞如此导致领域对象贫血。只有当实体与值对象承载不住或是本身并不属于实体或值对象的职责内时才考虑领域服务来承载领域服务是一种妥协的结果并不是说领域服务越多越好。值对象Value Object→ 实体Entity→ 领域服务Domain Service
如下场景创建 Invoice存在几条业务规则相应 Order 的状态需已完成并且对应的 Supplier 提供财月信息这就需要多个聚合的协作在领域服务编排这些领域对象模型及通过调用外部服务网关完成业务逻辑。// InvoiceManager
public async Task ValidCheck(string orderId, string supplierId)
{var order await _orderService.GetAsync(orderId);if(!order.IsCompleted()){throw new UserFriendlyException(Order status is not completed);}var supplier await _supplierService.GetAsync(supplierId);if(!supplier.IsCompleted()){throw new UserFriendlyException(Order status is not completed);}
}
public async Task SetFinanceMonth(Invoice invoice, string supplierId)
{var supplierFinanceMonth await _supplierService.GetFinanceMonthAsync(supplierId, Current.Date);if(supplierFinanceMonth null){throw new UserFriendlyException(Supplier not provider finance month);}invoice.SetFinanceMonth(supplierFinanceMonth.StartDate, supplierFinanceMonth.EndDate);
}
在应用服务中通过调用聚合及领域服务完成这一创建 Invoice 的用例。[UnitOfWork]
[Authorize(PermissionNames.Invoice_Create)]
public async Task CreateInvoice(CreateInvoiceDto input)
{await _invoiceManager.ValidCheck(input.orderId, input.SupplierId);var invoice Invoice.Create(input.Name, input.Description).SetOrder(input.OrderId);await _invoiceManager.SetFinanceMonth(invoice, input.SupplierId);await _invoiceRepository.InsertAsync(invoice);await _appNotifier.NewInvoiceAsync();
}
借助领域服务以此来完成多聚合间的协作通过应用服务编排领域模型对象完成一个业务用例。领域事件在软件开发中事件早已被我们所熟悉一个按钮按下产生中断事件一个回车前端页面有侦听事件在事件风暴建模活动中事件也是作为领域建模的突破口事件的重要性不言而喻。其本质是发生的事实到引发了相关事情在这其中的传递的信息便是事件的内容。就如同猫叫了引发着老鼠跑了主人醒了其中的事件便是猫叫了而该事件是猫执行叫的动作后的结果。在领域驱动设计中最开始的版本中并没有领域事件的概念在 DDD 社区对领域驱动设计的内容不断的充实中引入了领域事件。领域事件的命名遵循英语中的“名词 动词过去分词”格式如提交订单后发布的 OrderCreated 事件订单完成后 OrderCompleted 事件用以表示我们建模的领域中发生过的一件事情也符合着事件本身是具有时间特征。(EShopOnContainers 中一个例子)对于领域事件本身依据各层的使用方式及面对的目标不同划分出两种事件类型领域事件与应用事件(或集成事件)应用事件侧重于应用层的使用而领域事件沿用原领域事件的称呼更偏向于领域层。而又应侧重点不同又有着不同的使用方式如领域事件更多的是从领域模型中发布其最终接收者为当前聚合所在限界上下文而应用事件更为广阔从应用层发布其接收者为当前上下文或是其他上下文。基于限界上下文间采用的部署方式不同也存在着不同的通信方式如整个应用程序为单体则所有上下文在同一个进程内则上下文间事件交互时所采用的可以是进程内的事件总线或是进程间使用的消息队列而当在进程间时就不得不使用进程间的消息队列了。由于 DDD 中遵循一个用例对应一个事务在一个事务中更新一个聚合因此对于实际场景中需要变更多个聚合下我们常通过编排方式调用其他聚合的服务这不可避免的加重了对其他服务的依赖借助领域事件则可以很方便的降低这种耦合同时对于多个聚合的变更操作由单个聚合的事务变成了多个聚合的事务又依照实际影响的聚合情况有着不同的处理方式如多个协作的聚合为同一上下文内时可通过强一致性去保证数据一致性而处于多个限界上下文间的聚合时则可依照最终一致性保证数据的一致性。领域事件主要用途有从事件角度丰富了领域模型保证聚合间的数据一致性实现事件事件溯源和 CQRS 等限界上下文间集成(发布订阅模式)资源库在刚接触资源库(Repository)时第一反应便是这就是个 DAO 层访问数据库然后吧啦吧啦但是当接触的越久越发认识到第一反应是错的资源库更多的是对资源的管理而不仅仅是数据库中的数据数据库可以作为资源的一部分但不是全部我们习惯将对外部系统的调用称为外部资源的获取这也是将外部系统作为资源的一部分。对于聚合来讲资源库的作用是负责将聚合持久化到数据库的(通常是持久化到数据库)并且由于聚合根负责维持聚合的生命周期也就使得应考虑仅聚合根才应该拥有资源库这也是与 DAO 层不同的地方。在分层设计时考虑将资源库的抽象划分到领域层属于领域模型对象的一部分如同设计防腐层的抽象网关般资源库的抽象作为特殊的网关当在应用层或是领域层中操作资源库抽象时将资源库作为管理聚合状态的工具可以忽视基础设施层中对资源库的具体实现。而在考虑基础设施层中具体实现时可根据需要选择适合的工具以此来管理和操作资源。工厂聚合从 0 到 1 的过程可以通过多种途径创建一般来讲我们开发中常直接实例化或是反射实例化而对于聚合来讲整个聚合是一个整体命运共同体并且由聚合根掌握聚合的生命周期。通常我们可以借助几种方式来创建聚合组装聚合在创建过程中封装业务逻辑。聚合自身担任工厂在聚合根中实现 Factory 方法独立的 Factory 类用于有一定复杂度的创建过程或者创建逻辑不适合放在聚合根上借助其他聚合来创建其他聚合担任工厂角色借助构建者模式灵活组装聚合聚合根的创建有多种方式依据聚合内掌握知识的多少与创建逻辑的需要可灵活选择。//...
var partType PartType.Create(input.Name, input.Description).SetCategory(input.Category).SetFactory(input.FactoryName);
如借助构建者模式通过拆分许多小的方法将过多的参数拆分以此避免一个创建方法参数中满屏都是参数的情况需要考虑吧拆分的方法需要满足业务一致性如内部的一些属性间有约束条件下需要划分到一个方法中以维持一致性或不变性。学无止境从2004年领域驱动设计到现在已经有17年时间了并且在其中还有诸如六边形架构洋葱架构整洁架构等的出现考虑的侧重点不同衍生着大量的新概念也不断地完善着领域驱动设计的思想。在学习与理解领域驱动设计中总会有新的东西改变我们以往的思想见到的越多越发觉认识的越少这或许也是学起来有点阻力的原因吧。参考《实现领域驱动设计》- Vaughn Verno《领域驱动设计实践》- 张逸《软件架构编年史》- herbertograca领域驱动设计实现之路 - 滕云领域驱动设计编码实践 - 滕云Package by component and architecturally-aligned testing - Simon2021-01-18,望技术有成后能回来看见自己的脚步
