中机建设一公司网站,免费网站服务,南昌seo方案,wordpress 中文广告插件前言ABP框架一直以来都是用DDD#xff08;领域驱动设计#xff09;作为宣传点之一。但是用过ABP的人都知道#xff0c;ABP并不是一个严格遵循DDD的开发框架#xff0c;又或者说#xff0c;它并没有完整实现DDD的所有概念。但是反过来说#xff0c;认真学过DDD的人会发现领域驱动设计作为宣传点之一。但是用过ABP的人都知道ABP并不是一个严格遵循DDD的开发框架又或者说它并没有完整实现DDD的所有概念。但是反过来说认真学过DDD的人会发现所谓“完整实现了DDD严格遵循DDD概念”的开发框架其实并不存在。因为DDD本质上是在分析业务在“落地”的时候与代码有关但是关系并没有我们所认为的那么大。所以个人觉得从学习如何正确使用ABP框架去揣摩框架的部分功能的设计意图也是一种很好的DDD入门方案。先抛几个常见问题命名空间该如何组织AppService应该怎么写实体类应该充血还是贫血什么时候需要写领域服务DomainService领域事件(DomainEvents)应该怎么用框架并不会严格规定我们该怎么写代码但是DDD给出了指导性的建议。但如果我们不了解DDD那么所谓建议就无从说起。所以我们还是要从介绍DDD开始。DDD是一种业务分析方法DDD领域驱动设计是计算机软件行业为了项目能尽量趋向成功根据多年经验总结出来的一套业务分析的方法论。其核心是消化特定业务领域的知识并创建忠实反映它的软件模型。正确的实施并非极其困难错误的实施却很容易。DDD并不难只是中文资料相对缺少部分词汇初次接触有可能觉得过于抽象加上某些词的翻译版本不一样会有点晦涩的感觉。想找中文资料学习DDD的可以去博客园搜一下领域驱动设计这里首推ENode作者汤雪华的博客。本文重点在于普及不会讲的特别深入。要想讲清楚ABP开发框架和DDD的关系还是要从DDD的作用讲起。DDD的分析部分——顶层设计DDD有一些词汇统一语言问题空间解决方案空间领域子领域上下文绑定上下文Bounded Context 有些翻译成边界上下文简称BC上下文映射聚合实体值对象领域服务领域事件在分析部分也有人称之为战略设计其实就是自上而下的进行分析我们还不用管聚合、实体、值对象、领域服务、领域事件只要看前面这些比较抽象的词汇。统一语言DDD的第一件事是定义“统一语言”。什么是统一语言大概解释下统一语言是为了降低沟通成本口头、文档、代码等、减少歧义通过业务专家又叫领域专家就是非常熟悉业务的人核准和明确语义项目的官方语言可以认为是一份术语表由类似架构师的角色在确认需求的过程中提炼出草案并后续逐步完善——增加新词汇明确语义处理歧义、同义等。写代码最头疼的命名问题统一语言可以帮你解决。不仅是参考还是标准原则上不允许随便命名必须和统一语言保持一致。问题空间和解决方案空间问题空间和解决方案空间基本就是字面意思。形象点说问题空间是我们在白板上画的一个大圈圈写上“电子商务”。然后大圈圈里再画上一些线分割开来一部分是“C端商城”一部分是“后台管理系统”一部分是“供应链系统”。下图只是简化的示意图不具备参考意义真实场景需要更细化而解决方案空间可以理解为针对“问题”的“答案”解决方案空间的划分最终对应到我们的代码实现但这个粒度依然是很大的比如我们用一个VS2017里解决方案sln通常是一个单独的代码库关联的所有项目去实现“C端商城”另一个sln涉及的项目去实现“供应链系统”。所有sln合起来是这个“问题空间”的“解决方案空间”。当然有时候简单系统只需要一个sln就够了。除了代码的大粒度组织这往往也影响团队分工影响人员组织。子领域就是对问题空间的继续划分。划分的参考标准是统一语言中的某些词汇是否出现了歧义——部分词汇出现多重含义往往预示着存在子领域。每个子领域中的统一语言是一致的无歧义的。绑定上下文就是对解决方案空间不是VS2017那种解决方案的继续划分。所以子领域对应绑定上下文。而上下文映射就是搞清楚绑定上下文之间的关系上下游依赖关系下游依赖上游——下游上下文受上游上下文变更影响通常说的防腐层就是为了隔离这种影响。所有这些词汇其实核心思想非常简单四个字——“分而治之”。但是具体怎么“分”却没有固定的方案完全依赖个人对业务领域的理解程度。甚至这个划分方案是随着对业务领域理解的加深而持续变化的。体现到“落地”就是不断的调整架构或者重构代码。分析部分最擅长处理的两种场景一个场景是业务逻辑确实很多很难消化、提炼和组织。就是非常复杂也是DDD的主要目的——应对软件核心复杂性。另一个场景是业务逻辑还没完全清楚这一般是指初创企业特别是创新型企业没有行业参照自己摸索的情况下。两个场景都依赖“统一语言”的威力。前者可以通过统一语言促进理解降低沟通成本。后者可以通过统一语言来表现对业务现状的理解和展望其未来的走向。分析部分最重要的两个元素统一语言和绑定上下文是DDD分析部分最重要的两个元素。定上下文继续向下细分才会涉及每个绑定上下文的架构问题此时才开始考虑如何“落地”也就是下面说的策略部分选择支撑架构。关于DDD分析部分还涉及很多具体的指导方法请自行参阅文末所列相关书籍。分析部分进行顶层设计最重要的产出就是绑定上下文BC的划分及BC之间的关系上下文映射。DDD的策略部分——支撑架构众所周知DDD有一定的前期成本而它的好处是降低了一个系统后续的长期维护代价。所以为每个绑定上下文BC选择支撑架构实现方案的指导原则是看“软件的使用期限”。上面两句话其实有一点矛盾——看起来好像是用了就丢的一次性软件系统不值得使用DDD但是这个系统的BC是用DDD划分出来的。其实这里的DDD有歧义指的是DDD的一个推荐支撑架构——领域模型而我们前面分析得到这个绑定上下文BC是DDD分析部分的一个结果。也只有到了某个BC是核心业务需要长期维护、迭代演进的时候我们才会考虑用领域模型一种特殊的对象模型来实现这个BC的支撑架构。到这一步我们才涉及到诸如OOP开发语言ABP开发框架这些选择具体技术栈的问题。特殊的对象模型意思是对象模型关注对象和对象之间的关系即使贫血模型依然是对象模型特殊是指领域模型关注对象的行为即要求充血模型。我们先看看除了领域模型对于支撑架构还有哪些可能选择。CRUD也是一种支撑架构在看DDD相关的书之前我们往往认为CRUD相当low事务脚本相当low不管什么都该用领域模型这里不叫DDD了区分下来实现。这就有种拿着锤子看什么都像钉子的感觉。其实所有DDD相关书籍都在劝我们具体情况具体分析。如果是短期、一次性项目这里所有的讨论都是针对某个BC一般叫“快速应用程序”工期紧也是一种考虑因素自然什么熟用什么CRUD也行只要行得通。很多时候优先是解决问题。换句话说可以只追求 Make It Work只要项目是一次性的无需后续维护的。再如一个纯展示的项目可以直接套用一个现成的CMS系统而非投入人力去从头开发。只有当通用软件产品财务管理CRMCMS之类无法满足需求而且也无法简单通过一个阶段的定制投入就能解决问题时我们才需要采用领域模型去分析业务进行软件建模。这通常也是老板为什么需要组建一个自己的技术团队的原因。ABP中的DDD构件所以任何开发语言任何一个能实现CRUD的框架都可能作为DDD指导下划分出来的某个BC的支撑架构的实现选择。DDD并没有贬低非领域模型式的支撑架构而是平等的对待它们因为总有合适的场景只是依赖个人的经验。直到这里我们才开始涉及ABP框架。分而治之从大到小前面我们讲到在统一语言中根据同个词汇的多重含义的线索我们可能将一个问题空间划分成多个子域为每个子域确定绑定上下文BC。这可能涉及到多个VS解决方案sln文件我们先假设只有一个VS解决方案。我们通常通过ABP官网的项目模板来初始化我们自己项目的VS解决方案。在下载完成解压后我们可以观察下程序集名称和默认命名空间这里可以参考ABP系列——QuickStartB:正确理解Abp解决方案的代码组织方式、分层和命名空间。接下来以Personball.Demo.sln为例对于解决方案Personball.Demo.sln我们发现多数类库程序集的默认命名空间是Personball.Demo。再下一层一般就是实体名称的复数形式命名的文件夹跨程序集保持一致。注意命名空间的层次是没有限制的而且默认对应了文件夹层次结构。所以对于一个解决方案中容纳多个BC我们可以通过命名空间来体现BC的隔离。在BC之上我们描述架构可能是一系列草图主要用于分析边界、BC之间的关系做一些顶层设计。当各个BC的边界划分明确后开始分析一个BC内的业务我们就用到了聚合和实体的概念。实体的定义很简单ABP有实体的泛型基类EntityT其中主要就是一个属性Id。其他的FullAuditedEntity或者CreationAuditedEntity都是框架提供的方便审计的基类扩展。所以实体就是领域中具有唯一标识的对象。从命名空间上看我们可以给BC一个名字让它逻辑上“统领”一部分代码这些代码主要就是一些实体类。但是实体类也是有主次之分的。典型的例子就是Order实体和OrderItem实体。虽然OrderItem有自己的id但我们几乎不会单独引用OrderItem因为单独一条OrderItem几乎不会有业务意义不能说死不排除个别我没见识过的业务场景。一个Order有多个OrderItem对OrderItem的操作通过Order进行代理这里Order就是聚合根。把一组实体放一起就是聚合其中作为主要代表的实体即是聚合根。聚合之间只能通过聚合根进行引用不能直接引用聚合中的非聚合根实体。按Order来说其他聚合要引用Order的时候记录的是OrderId或者订单号假设其他聚合要处理某个Order的OrderItem它也只能引用Order让Order去处理它自己的OrderItem。这其实是一种内聚的思想或者叫封装或者叫关注点分离总之是一种复杂性的隔离划分BC也是一种复杂性的隔离。我们一开始看到ABP的AggregateRootT和IAggregateRootT几乎是懵的项目模板中也没有这个基类的范例。再看看这个基类提供的属性DomainEvents以及ABP框架中涉及该属性机制的源码看AbpDbContext的SaveChange方法实现。这时候我们看到了事件怎么用开始思考领域事件这个词开始去学习DDD。当我们开始思考事件的时候我们很自然的就会去思考实体的行为方法。我们通过实体方法实现实体自己能够处理的业务逻辑。以“Tell,Not Ask”的原则实现实体的行为。在行为成功完成后抛出事件以便外部协同。而聚合根继承AggregateRootT基类或者实现IAggregateRootT接口作为其他实体的代理实现本聚合内的逻辑通过DomainEvents收集各类事件交由ABP框架底层来触发事件实现跨聚合甚至跨BC的协同同时事件的发布订阅模式也是一种逻辑代码的解耦顺序无关EventHandler也可以回滚工作单元。另外DDD中的仓储模式是基于聚合根实体的聚合根同时代理了非聚合根实体的仓储职责就是说OrderItem不应该有自己的仓储接口和实现这一点在ABP中并没有严格限制或许是ABP作者不希望把框架的使用门槛定的太高。实体聚合根也是实体只能实现自己控制范围内的业务逻辑控制范围外的呢所有无法放到单个实体内实现的业务逻辑都可以放到领域服务中实现。这包含需要同一个实体类的多个实例配合的需要不同实体类的多个实例配合的还有其他。只要一个实体的实例无法自己完成这部分逻辑就需要构建领域服务。最后最小的DDD构件值对象。ABP框架中有一个基类ValueObjectT即用来表示值对象。其实DDD中的值对象对应到代码有一个很宽泛的范围可以认为所有没有唯一标识的数据对象都是值对象。 最基本的比如C#语言的值类型像string,int,decimal都是值对象。那么我们为什么还需要一个基类来辅助构造值对象第一个原因是值类型业务表达能力弱。 通过float我们可以知道数量但是不知道是重量还是体积通过decimal我们能表示金额但是不知道是人民币还是美元。所以我们需要自己构建值对象来更准确的表达业务概念。第二个原因是方便。值对象只能通过各个属性的具体值比较来唯一确定这个基类帮我们重写了Equals()和GetHashCode()并重载了相等和不等操作符。但这里有个坑值对象必须保证其不变性具体看Abp系列——为什么值对象必须设计成不可变的而ABP框架是无法控制你如何使用ValueObjectT的子类的。具体地说你的值对象必须关闭所有属性的setter必须通过构造函数来初始化且不允许通过方法改变属性值。忘了分层应用服务层和基础设施层上面讲的聚合、聚合根、实体、值对象、领域服务、领域事件基本都是领域层。DDD讲领域模型支撑架构的时候特别提到分层也是我们从ABP中学到的分层方式表现层、应用服务层、领域层、基础设施层。表现层并不特指前端界面MVC框架也只是一种表现层框架它只是特别擅长处理Http协议。应用服务层就是Application程序集是DDD建议的体现用例的一层直接对接表现层类似MVC控制器的协调作用接受请求返回DTO/ViewModel用来编排任务将工作指派给下层。所以应用服务AppService的代码根据用例进行组织即可。领域层即是业务模型的完整实现。基础设施层侧重于持久化技术比如EF但是不限于持久化技术通用功能接口的具体技术实现类似仓储接口定义在领域层实现放在基础设施层。ABP按照ORM框架名称作为基础设施层的程序集命名可以理解但不能被其限制。个人建议另开一个程序集如Personball.Demo.Infrastructure依赖于Personball.Demo.EntityFramework再让启动模块依赖Infrastructure模块。扩展CQRS和事件溯源当我们说经典领域模型的时候指的就是基于对象模型来实现业务数据存储走关系型数据库一切看起来都很完美。但是DDD研究的是复杂性。软件开发行业几十年的经验累积下前辈们发现如果把软件功能分成两方面假设系统中查询部分的复杂度是N命令创建或变更数据部分的复杂度也是N。那么经典领域模型的情况下系统的命令和查询混在一起这个总体复杂度就是N乘以N如果分开那么系统总体复杂度就会降低到N加N。另一种说法是对象模型的局限性日益显现现在发现关注事件比关注对象更方便业务建模因为现实世界是基于事件的。这引导我们可以使用函数式编程来实现支撑架构同时也引出了事件溯源架构。CQRS命令与查询职责分离正如其字面上的意思一个相当简单的原则却非常有效的降低了系统的复杂性。这里并不是要推荐一个CQRS开发框架只是提一下大家可以在任何开发框架任何场景下按CQRS的方式去思考都可以获得实际的好处。再理一遍统一语言问题空间、子领域解决方案空间、绑定上下文/上下文映射、聚合/聚合根、实体、值对象如果还有不明白的可以参考下列书籍如果还想深入学习的可以参考下列书籍。希望本文能对你有所启示由于本人水平有限若有表达错误的地方欢迎斧正。相关书籍《Microsoft.Net企业级应用架构设计》架构师参考书后半本基本都是讲DDD的也是本文的主要参考这本最近刚重新看完也在整理思维导图下面几本专讲DDD的还没复习忘得差不多了《领域驱动设计》又称DDD《实现领域驱动设计》又称IDDD《领域驱动设计模式、原理与实践》又称PPPDDD英文版书名三个P开头的词在前面原文地址:https://personball.com/ddd/2018/12/07/from-abp-to-ddd-i.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
