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

相关文章

来自专栏大数据文摘

超越批处理的世界:流计算

2034
来自专栏CDA数据分析师

【实战】Python 读写 Excel 实例应用

学习了简单的 Python 操作 Excel 的两个库 xlrd 和 xlwt,今天来实际操作一个案例来增强实战功能。 案例背景 我们市场部的同学想通过分析广告...

1895
来自专栏BestSDK

Google发布Nearby Connections API 2.0版本,可拓展本地信息和数据分享

关注过 I/O 2017 开发者大会的网友们,或许还记得 Google 提到过的“情境应用体验”(Contextual App Experiences)。这组 ...

2954
来自专栏Java3y

从零开始写项目第五篇【评论功能、备忘录】

评论功能资料 在网页上评论功能并不少见,我也想在自己的网站中增加评论功能,好让知道别人对我的网站的看法,还能让别人提醒我哪里出错了。 于是我就去寻找对应的资料去...

3478
来自专栏领域驱动设计DDD实战进阶

DDD实战进阶第一波(十五):开发一般业务的大健康行业直销系统(总结篇)

1253
来自专栏ThoughtWorks

从2016年11月期技术雷达看前端的未来|洞见

黄峰达 ThoughtWorks 本文仅代表作者个人观点,来听听一个前端程序员的YY。 新一期的技术雷达有点出乎意料,使用new标签的框架、工具、技术、语言等...

2603
来自专栏智能算法

软件全程建模

在软件工程的全部实施过程中都采用模型的方式而非文字的表达方式来进行描述,这样的实现过程称之为全程建模。全程建模的特点是:模型相互之间是有关联的,模型成为软件工...

3417
来自专栏WeTest质量开放平台团队的专栏

双十一临近,怎样让买家流畅地秒杀? ——腾讯 WeTest 独家开放电商产品压测服务

从拍脑袋到场景化压测,双十一的现象级大促从来不是一蹴而就。

2200
来自专栏IT技术精选文摘

Node全栈为前端带来更多可能

1494
来自专栏数据派THU

数据蒋堂 | 存储过程的利之弊

来源:数据蒋堂 作者:蒋步星 本文长度为2240字,建议阅读5分钟 本文通过剖析存储过程的优点,探查存储过程的潜在风险及应用场景。 存储过程是数据库领域中应用非...

1868

扫码关注云+社区