BrightLiao 最近的时间轴更新
BrightLiao

BrightLiao

V2EX 第 90088 号会员,加入于 2015-01-05 16:28:25 +08:00
数据应用测试实践分享
程序员  •  BrightLiao  •  4 天前  •  最后回复来自 BrightLiao
1
我做过的一些 DDD 建模案例
  •  1   
    程序员  •  BrightLiao  •  79 天前  •  最后回复来自 BrightLiao
    5
    mac 下大家都用什么鼠标
    调查  •  BrightLiao  •  90 天前  •  最后回复来自 yule111222
    1
    BrightLiao 最近回复了
    4 天前
    回复了 BrightLiao 创建的主题 程序员 数据应用测试实践分享
    上面的链接错了,现在没法改了。请感兴趣的同学用这个链接: https://brightliao.com/2021/04/20/data-testing/
    5 天前
    回复了 qinrui 创建的主题 程序员 怎么避免自己写的代码变成屎山?
    一旦你看你的代码快要变成山了,就得考虑是不是代码垒得太高了。拆分成两座或更多的土丘是大多数人的选择。

    考虑:
    - 从技术上看,有没有模块是非常复杂的,但是是独立的。如有,拆出去,专门给某个人或团队维护。
    - 从业务上看,有没有两个业务本来就是相关性很低的,考虑拆分为不同的项目,交给不同的人维护。

    现在大家在谈微服务,其实就是谈拆分,如何避免一个项目内的东西过于复杂。
    很好的建议!我觉得团队甚至整个业务线、整个公司最好能建立一个缩写词库。DDD 中强调团队统一语言,这里的思路如出一辙!
    79 天前
    回复了 BrightLiao 创建的主题 程序员 我做过的一些 DDD 建模案例
    真正的 ddd 其实和语言没什么关系,主要是来源于对要解决的问题的深入思考。当然,ddd 会对大家有一些技术背景要求,面向对象、函数式编程这些基本的技术需要掌握,solid ,cupid 这些好代码的原则需要知道。这些基础技能不熟悉,我们就会想要基于某个特定编程语言去学 ddd ,其实这是本末倒置了。
    115 天前
    回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
    @yule111222

    聚合我也认为没什么不好(前提是设计合理),我也经常用,只不过在 smart domain 中聚合被弱化了,运行时就是一个复杂的对象图(在一个独立的内聚的领域里看,这本来就是事实)。如果要从 smart domain 对象图里面寻找聚合,一般而言,就是通过内存模型关联的一组对象。但是 smart domain 的灵活性在于可以透明的将内存关联变为数据库关联,甚至跨服务关联。

    不过将 smart domain 和直接引用的聚合结合起来用,也是值得尝试的。事实上,我在文章中也提到可以尝试这样做。
    115 天前
    回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
    @yule111222

    DDD 的要旨之一是建模人员是 Hands-on modeler 。所以,虽然可以有概念建模和领域建模的阶段,但是这只是建模过程的初始一小段,建模是要在整个软件开发过程中持续进行的(建模的结果绝不仅仅是发现了几个名词,还包括要深刻的建模业务规则,通过引入新的概念来抽象和简化规则)。事实上,如果初始的各种图没有持续更新,很快就会变成没用的或者误导团队的废纸。

    如何做好建模呢? DDD 原书提到可以:

    - 大声的建模(第 2.2 节):充分利用人类的语言天赋,大声的讨论、交流,最终得到一个统一的大家都理解的语言。“这个过程可以帮我们精练模型”。这是可以用 TDD 来驱动实现 DDD 的支持之一,因为在还没有代码的时候写测试,我们只能利用自己的语言能力去描述解决问题的过程。
    - 绑定模型和实现(第 3 章): 在进行 DDD 时,不能将建模过程和实现过程分离,因为实现的一点点改变就意味着模型的改变。如果有人只关注建模而不关注实现,则他的建模没有用处,实际的模型将牢牢掌握在实现这个模型的开发人员手中。所以 DDD 的建模人员需要是 Hands-on modeler 。TDD 其实就是 Hands-on modeler 的武器。
    - 通过重构加深理解(第三部分):在已有代码的基础上,从多个方向进行重构,尝试不同的建模想法,创造突破,从而得到更深刻的模型。TDD 产生的测试在重构的过程中为我们保驾护航。

    TDD 的价值不只是在于测试覆盖,这只是它的一个副产物而已。TDD 的更大的价值在于可以用于改善设计(也即驱动 DDD ),我的另外几篇文章里面有一些思考:

    - 从改善设计的角度理解 TDD: https://brightliao.com/2019/07/20/tdd-for-improving-design/
    - 从改善设计的角度理解 TDD ( 2 ): https://brightliao.com/2019/08/18/tdd-for-improving-design-2/
    - 好代码的五个特质 - CUPID (基于领域的章节): https://brightliao.com/2022/05/24/5-properties-of-good-code-cupid/

    初始阶段进行一定程度的概念建模和领域建模是有用的,但即便在这个过程,TDD 也可以帮助我们提取和改善领域模型,除非我们的目标只是产出一个不知道是不是可以实现的设计文档(而不是一个可运行的 MVP )。从整个开发过程来看,在比初始阶段长的多得多的开发时间里进行建模,TDD 是有很大作用的。
    115 天前
    回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
    @yule111222 我一般的做法是用 TDD 来驱动复杂场景的模型设计,从而尽可能丰富领域模型,同时还顺便把测试加上了。所以,我会觉得用 TDD 可以驱动实现 DDD 。(简单场景的话,凭经验进行设计就搞定了)

    打一波广告,最近刚开源了一个用于进行 ETL 开发的工具和库: https://github.com/easysql/easy_sql
    有兴趣的同学可以研究一下里面的领域模型设计及测试(目前有 80%+的测试覆盖率)。
    115 天前
    回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
    @yule111222
    聚合的问题在于粒度难以把握。现在大家都倾向于用小聚合,那么多小合适呢?之前的小聚合,是不是可能由于聚合内的实体逐渐变复杂而需要拆分呢?
    测试更加不是一定要有聚合的理由。如果逻辑拆分合理,每一个实体应该都有自己的业务能力。测试应该针对每个实体的公开 API 来测试。如果直接对聚合上面的 API 来测试,则会把分散到各个聚合内的实体的业务逻辑一并测试到,从而导致需要覆盖的场景特别多特别复杂。

    以上是个人的理解。
    116 天前
    回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
    @yule111222 欢迎回来分享使用经验啊!
    116 天前
    回复了 BrightLiao 创建的主题 程序员 我理解的 Smart Domain 与 DDD
    @jamel
    分层架构的问题是,容易让开发人员把注意力放在分层上(导致领域模型抽象不足),而忽略了领域层建模才是 DDD 的核心。Smart Domain 可以把大家的注意力转移到领域层建模上。
    就像 Eric 说的 DDD“远远不只是 ‘发现名词’,业务活动和规则如同所涉及的实体一样,都是领域的中心… 当我们的建模不再局限于寻找实体和值对象时我们才能充分吸取知识… ”。

    其实,在分层架构下,对于合理的分层,现在的框架都有很好的支持,基本上都是利用框架的能力实现了。这也是应该弱化分层的理由之一。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2006 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 17:00 · PVG 01:00 · LAX 09:00 · JFK 12:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.