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 条评论
登录 后参与评论

相关文章

来自专栏程序员互动联盟

读不懂英文文档,能写出代码不?

作为一个开发人员,开发一个新项目,维护一个项目,想要快速的开展工作。最重要的是干什么?是阅读项目文档,没文档看代码。可见我们首要做的事情是看文档看懂文档,编程初...

30450
来自专栏Java帮帮-微信公众号-技术文章全总结

2016年Java和JavaScript编程方面的趋势

最新版JavaScript的变化 2015年6月,JavaScript/ECMAScript 6(即ECMAScript 2015或ES6)发布。根据之前的预测...

38390
来自专栏FreeBuf

安卓耗电之谜:罪魁祸首竟是隐藏通信

简介 我们目前并不清楚为什么Android有这么多使用远程服务器进行隐藏通信的app,尤其是这些隐藏通信其实并没有被智能机主使用。我们知道app是从云端传入传出...

21490
来自专栏IT大咖说

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

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

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

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

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

1.8K50
来自专栏腾讯技术工程官方号的专栏

2017 全球移动技术大会

导语 6月9日-10日,“2017年全球移动技术大会(GMTC)”在北京举行。会议为期两天,面向移动开发、前端、AI技术人员,聚焦前沿技术及实践经验,打造技术人...

34770
来自专栏PPV课数据科学社区

【译文】怎样学习R(上)

有奖转发活动 回复“抽奖”参与《2015年数据分析/数据挖掘工具大调查》有奖活动。 ? 何品言翻译,广东科技学院大学生,喜欢R语言和数据科学。 王陆勤审核,从事...

36160
来自专栏流柯技术学院

性能测试之吞吐量

我们每天的生活中都在用水用电,我只会关心自己的水管是否有水,水压是否稳定,如果我们把水龙头拧到最大,还是一滴一滴的流水。那我们就要愤怒了,直接找房东问明情况。我...

52140
来自专栏Kirito的技术分享

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

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

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

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

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

12920

扫码关注云+社区

领取腾讯云代金券