DDD 畛域驱动设计落地理论系列：工程构造分层

编号27149

引言
后面几篇文章中，笔者给大家论述了 DDD 畛域驱动设计的三大进程，重点环抱如何经过策略设计与战术设计进行 DDD 落地理论进行了具体的探讨，然而尚无波及到工程层面的落地。实际上一切的这些架构实践到最初都是为了使得咱们代码构造更为明晰，从而开收回 bug 少、扩展性强、逻辑分明的运用。因此本文就是为理解决 DDD 畛域驱动落地理论最初一千米问题，将咱们剖析出来的畛域模型经过与工程构造的映照完成真实的落地。
DDD 畛域分层
当咱们实现畛域模型构建之后，咱们需求先肯定下微办事外部的畛域分层构造，由于这个畛域分层的好坏间接抉择了咱们微办事的工程构造是不是公道，调用逻辑是不是明晰。而这些畛域模型都需求映照到实际的代码，咱们开发的代码究竟应该放在哪一层，放在哪些目录中，都需求依靠于畛域封层的后果。然而真实的畛域驱动设计在怎么标准代码构造下面实际也没有详细的标准，因此咱们需求按照本人的理论教训以及思考进行划分。


分层的目的实际上就是让各层的逻辑能够分工合作、各司其职，防止不用要的代码相互净化。同时构造明晰的分层构造也对比便于前期的重构以及拆分或者合并，实际上也是一种在为将来可能存在的变动节俭研发本钱。
这里需求阐明的是，在传统的畛域分层中，是将根底设施层作为其余三层的依赖的，然而实际上这类形式是有问题的。为何这么说呢？由于假如咱们真的根据用户接口层、运用层以及畛域层都依赖根底设施层的话，那根底层就成为了最中心的层级了，然而实际上畛域层才是真实的中心，这显然违抗了 DDD 以畛域为中心的设计思想。因此咱们使用依赖颠倒的形式，让根底设施层去依赖畛域层，这样做的益处就是能够让畛域层更为的职责繁多以及更为的纯正，他不需求关怀数据是怎么来的，无论是数据库查来的仍是缓存萃掏出来的仍是从内部查来的，它只需求关怀它本人畛域内的业务逻辑就能。既然咱们明白了该怎么进行畛域分层，那末各层的数据组织方式是怎么样的呢？
各层数据对象
VO（View Object，视图对象）：该层的视图数据对象次要的作用就是将运用层的数据进行组装后造成用于页面展现的视图数据。
DTO（Data Transfer Object，数据传输对象）：DTO 次要作为 Application 层的入参和出参，用于用户接口层与运用层之间的数据传输。
Model（畛域对象）：畛域对象是咱们正常业务应该用的畛域业务模型，它的字段和办法应该和业务言语放弃统一，不需求进行耐久化和序列化，他次要存在与内存中。也就是说，所以 Model 和 DO 可能字段属性都纷歧样。
DO （Data Objec，数据对象）：个别都是使用 PO 作为耐久化的数据对象，然而笔者习气使用 DO，由于我感觉数据对象固然要和数据库中的字段相对于应的。因此从称号来讲，DO 作为耐久化对象我想更为适合一点。
数据流转
上文中分别说到了畛域分层构造以及各个数据对象的不同含意和用处，那末咱们接上去就看下各个数据对象在 DDD 的各个畛域分层中是怎么进行数据流转的吧。
在用户接口层，它需求接纳来自 WEB 端、APP 端以及其余的内部数据申请，并将申请经过 DTO 向运用层进行传递，按照运用层前往的 DTO 数据，再将 DTO 转化为页面需求呈现的 VO 数据，进行最初的页面展现。
当申请抵达运用层后，假如需求调用内部办事的接口，那末咱们需求经过运用层的防腐层进行调用。那末为何需求防腐层进行调用而不是间接调用呢？次要的缘故就是为了隔离接口数据变动，避免内在办事的数据变动影响运用层的代码，假如真的需求修正那末间接在防腐层中进行修正就行-了。
在畛域层，我通常使用的是 model，能够了解为业务畛域模型，次要包罗实体以及值对象。在运用层会将 model 作为参数进行畛域层接口的调用实现中心的业务逻辑。在一些其余的书中，得多人喜爱使用 DO 来作为畛域层的数据承载对象，然而我集体仍是感觉 model 更合适，由于从称号下面更好了解一点，更为直观一点，一看就知道是模型，甚么模型，固然是业务的畛域模型。
畛域层中包孕了仓储的接口，详细的完成在根底层中，这是一种依赖颠倒的设计形式，完成畛域层与根底层的解耦。其余的书中喜爱使用 PO 作为这层的数据载体，我习气使用 DO。由于 DO 就是数据对象，自然的和数据库应该对应在一同，笔者一样感觉这样更为直观。详细怎么用仍是看各位在实际落地使用的时分的习气吧。


畛域模型与代码模型映照
工程分层


如上图所示，咱们在微办事拆分后，将微办事外部的代码层级次要分为 interfaces、biz、domain 以及 instructure 这四层，分别对运用户接口层、业务层、畛域办事层以及根底设施层，留意这里的 biz 层实际就是 application 层，用为笔者感觉 application 层欠好了解，而 biz 层更好了解一点，实际他们的功用是同样的，只是为了减低下了解的本钱。
interfaces 层：就是用户接口层，这里次要寄放一些与前端交互的代码以及与其余办事交互的接口，次要的作用将将前端申请转化为适量数据去调用 biz 层的业务代码进行业务申请，此外将 biz 层前往的数据进行组装终究造成页面所需求的数据。
biz 层：其实就是 application 层，然而我更违心叫 biz 层，由于这层的作用实际就是进行办事组合以及办事调度的，实际它是基于上层的畛域办事去实现业务逻辑流程的，因此我感觉叫 biz 层更为贴切一点。
domain 层：这是全部微办事的中心层，次要包孕了畛域模型、畛域办事以及中心的业务逻辑。畛域模型次要包罗了聚合中的聚合根、实体以及值对象，畛域事情也会放在这一层中。
instructure 层：根底设施层次要包孕了各种通用才能以及工具类，它的作用就是为下层提供根底办事的，如数据库办事、MQ 办事以及缓存办事等还有其余的一些配置以及资源。
代码归位
1、interfaces 层
（1）assemble 次要担任完成 vo 与 dto 之间的数据转换任务。
（2）vo 寄放需求呈当初页面的视图数据对象。
（3）facade 次要完成本层的接口封装。


2、biz 层
根据我本人的习气，笔者是根据互粉的畛域来进行包构建的，好比这里的 user 以及 authority 就是不同的畛域。为何这么划分呢？次要斟酌到将来万一有新的拆分，咱们能够间接根据对应地区进行拆分，效力要比在不同包中一个一个类找相干的高很多。此外根据畛域划分也对比明晰。能够便利的相熟业务。
（1）dto 中次要放了数据传输对象，biz 层接口的入参以及前往值都是 dto。
（2）service 就是 biz 的接口以及接口完成，次要的作用就是完成关于畛域办事的编排以及组合，从而实现详细的业务流程。
（3）event 次要放的是事情公布以及定阅的相干代码，实际详细的事情中心逻辑能够放在 domain 层中进行处置。


3、domain 层
说瞎话，之前咱们常常使用以数据驱动的设计以及开发形式，大部份的业务逻辑都是在 biz 层实现的，然而畛域驱动设计和数据驱动设计最大的不同就是，大部份中心的业务逻辑需求下沉到 domain 层中。实际一开始进行这类形式的开发的时分十分的不习气，然而当你实际沉下心来做的时分会发现，确实这类开发形式更为的能体现 DDD 的劣势。此外这里仍是按照畛域进行划分，和 biz 层是同样的。
（1）event 次要放事情处置的中心逻辑代码。
（2）model 中就是详细的实体。
（3）repo 次要寄放耐久化的代码。
（4）service 次要寄放畛域办事的中心业务逻辑代码。
（5）valueobject 次要寄放值对象。


4、instructure 层
这层的话次要寄放一些根底两头件的链接配置代码以及 domain 的 repo 完成代码以及其余一些资源类的代码。


总结
DDD 畛域建模设计的实践中并无对工程构造怎么落地实际的代码做出硬性规则，本文次要按照笔者本人的一些思考以及理论教训梳理了畛域模型与代码模型映照的构造，但愿对大家再各自业务落地 DDD 理论的时分有所参考。到这里咱们完成 DDD 落地的一切筹备任务都差未几了，前面的文章中咱们将按照真正的业务场景进行真实的落地理论，从业务剖析到畛域建模，从畛域分层到代码完成。我想经过这一系列的实践加理论的形式，置信大家能够真正领悟到 DDD 的魅力所在。