DDD(领域驱动设计)的这些问题,你都知道吗?

本文中的问题精选自上期【你问我答】——DDD(领域驱动设计)专题中读者的提问。【你问我答】是由美团点评技术团队推出的线上问答服务,你在工作学习中遇到的各种技术问题,都可以通过我们微信公众号发问,我们5000+工程师会义务为你解答,欢迎大家踊跃提问。高质量、定义清晰的问题会优先获得解答。

编者按

DDD就是帮助工程师快速理解和提炼业务本质或核心的一套方法。

DDD又分战略设计和战术设计,这两个混一块就没法谈了。战略设计就是画一个圈,把里面的模型建出来。战术设计就是,在物理层次想尽一切办法保证边界不被突破和内部模型的状态的一致性,具体怎么落地有各种各样的做法,这时考验的是工程设计能力。

另外,因为DDD属于一种思想,所以大家对同一个问题可能有不同的看法,这些看法虽然不同,却为我们解决问题提供了多样化的思路,所以我们这次将不同同学的回答都放置在问题下面,希望对大家有所帮助。

Q1:我使用事件、工作单元、观察者模式简单使用了下领域事件,接下来想做成事件与业务在同一数据库事务中写入表,然后异步执行。这一块你们有怎样的使用方案,遇到过什么问题需要注意些什么?

A1:系统设计上区分存储层和产品层,好的存储层/模型可以支撑若干差异产品流程和玩法。 A2:这个问题没太理解,感觉这位同学说的已经是解决方案了,不是在说问题。试着回答下:一是要注意事件引擎是不是作为中间件建设的,如果是的话,这样做有一定的入侵性,但是能获得较好的事务保障;二是事件落地会带来一些数据库操作,会带来额外的数据库负载,根据你设计的事件粒度和事件处理状态粒度,这个开销会非常可观。

Q2:我在设计服务RPC接口时,遵循了一个规则,就是参数类只包含所需的字段,不多不少,也担心以后可能加不同的字段,所以为每个接口创建了单独的参数类,从而导致类泛滥等各种问题。后来想了办法,使用聚合方式拆分成小粒度的参数类,接口就多几个参数而已,就是可能会超过3个这点不好,但不像以前麻烦了,你们是怎么做的?其实聚合或领域服务都会有超过3个参数的情况,你们是否允许这样? 服务接口实现我觉得就是应用层,MVC控制器是用户接口层,我的理解是否正确?另外接口需要先校验参数,比如非空枚举值校验,还是有必要的,但聚合和实体中也有这样的校验,感觉参数校验是泄露了领域逻辑,该怎么正确理解?

A1:根据六边形结构,领域层暴露领域层接口,应用层暴露应用层接口。如果是命令接口,必须由适配层转换为六边形内部定义的参数。如果是查询,根据CQRS理论,怎么方便怎么来。 A2:如果使用事件,对应问题是事件的前置达成条件,是以存储层成功为准还是产品层成功为主。所以存储层和产品层之间的关系和定位需要先想好。

Q3:DDD中的自治和微服务的自治有区别没?

A1:DDD只做六边形内部的状态自治,和SOA的服务自治是正交的。 A2:事务是另外一件事,是存储层/存储介质来关注的。我个人认为事件与事务没关系(我个人在实施上存储和产品是隔离的)。 1. 服务自治:DDD和微服务的关注没区别。理论基本一致,DDD多了落地的指导。 2. DDD多了一个业务自治,这个是最难的部分。 A3:服务自治:自治分功能自治和质量自治,DDD主要是功能部分,也就是业务,微服务两者皆有。

Q4:做SOA时,如果一个服务内需要调其它服务接口,我考虑的办法是当前服务内创建对应的聚合实体仓库,仓库实现类里调用其它接口。这样做是否合适,你们有其它方法没?不过这样给人一种本地事务的感觉,如果有事务补偿,就有点别扭。

A1:我只在数据读取的时候这么做,涉及到数据更新千万别这么做…… A2:事务补偿如果做到框架里面,或者通用解决方案,就不会觉得别扭了。

Q5:看书上的例子觉得很有用,但是看自己遇到的业务场景又觉得没有用。拿创建订单来说,“创建”这个动作应该放到哪里比较好呢?

A1:创建订单就用订单工厂,这个和DDD没太大关系,就是设计模式的应用。 A2:个人认为这个需要具体看。订单只是一个业务的概念,需要根据具体的业务需求,来定义订单这个词映射在领域语言中是什么。也许就是商家和用户之间的一种“合同”,亦或许只是个“日志”而已。

Q6:请推荐一些靠谱的资料,能够让我快速掌握DDD的大方向。

A1:《实现领域驱动》、Jdon网站关于DDD的讨论。 A2:领域设计和服务化的区别,是对领域的理解、抽象、组合。 所以先看OOA、OOD、OOP会更有帮助。否则实施的结果,只是在做服务化。

Q7:请教,如何区分领域边界,是否可以分享一下经验。

A:限界上下文的提取貌似没有一个固定的办法,我习惯先收集领域词汇,在领域词汇里找到可能成为独立系统的叶子节点,然后在叶子节点中寻找内在联系,将叶子节点聚合在一起形成限界上下文,最后再站在客户角度和行为分析的角度修正一下。

Q8:如果对2个聚合的“读取并统一返回的”操作,这端逻辑是放在领域服务还是放在应用层比较合适?

A:个人理解是应用层,CQRS最初就是为了解决这种问题提出来的。

原文发布于微信公众号 - 美团点评技术团队(meituantech)

原文发表时间:2017-10-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

魅族大数据之用户洞察平台

摘要 魅族DMP(用户洞察平台),通过对三方受众数据的汇聚、清洗、智能运算,构建了庞大的精准人群数据中心,提供丰富的用户画像数据以及实时的场景识别力。对内:无缝...

3856
来自专栏Java架构

这些分布式知识,BAT的架构师都在用!

前一段时间在网上看见了一篇文章内容大致是作为一个架构师你需要拥有什么样的能力,其中不过是包括以下几个点:

4287
来自专栏微信终端开发团队的专栏

微信 Android 模块化架构重构实践(下)

重构整体架构不是一件容易事,通常也不太可能让整个团队停下来只做重构。本文是微信 Android 模块化架构重构实践的下篇,主要分享模块化架构重构的一点点经验。

1.3K5
来自专栏Kirito的技术分享

以Dubbo为例,聊聊如何为开源项目做贡献

Github 上有众多优秀的开源项目,大多数 IT 从业者将其当做了予取予求的工具库,遇到什么需求,先去 Github 搜一把,但有没有想过有一天自己也可以给开...

1183
来自专栏全华班

微信公众号、小程序、接口统一集成开发平台框架

RhaPHP微信平台管理系统,支持多公众号管理,小程序开发,APP接口开发、几乎集合微信功能,简洁、快速上手、快速开发微信各种各样应用。简洁、好用、快速、项目开...

3222
来自专栏大数据和云计算技术

​大数据和云计算技术周报(第35期)

“大数据” 三个字其实是个marketing语言,从技术角度看,包含范围很广,计算、存储、网络都涉及,知识点广、学习难度高。

1052
来自专栏phodal

GitHub 寻宝指南

作为一个资深的咨询师、程序员,GitHub 是我用过的最好工具,因为 Google 并非总是那么用。GitHub 是一个宝藏库,可没有藏宝图,GitHub 一1...

852
来自专栏大数据钻研

Web前端知识体系大全

1、前言   大约在几个月之前,让我看完了《webkit技术内幕》这本书的时候,突然有了一个想法。想把整个web前端开发所需要的知识都之中在一个视图中,形成一个...

3694
来自专栏腾讯移动品质中心TMQ的专栏

【探索式测试基础系列】初恋的味道

在学习探索式测试的过程中,也会有酸甜苦辣,只有了解它的人才知道这种味道。不妨和探索测试一起再回味一下初恋的味道。

1.5K10
来自专栏程序员互动联盟

单片机距离智能机器人有多远?

提到单片机很多人都很觉得不陌生,大街小巷上面电子产品都用到。近几年随着嵌入式的发展,智能机器人是未来一个大方口,其实智能机器人也是嵌入式的一种,里面融入了生物科...

3445

扫码关注云+社区