很好的建议！我觉得团队甚至整个业务线、整个公司最好能建立一个缩写词库。DDD 中强调团队统一语言，这里的思路如出一辙！

真正的 ddd 其实和语言没什么关系，主要是来源于对要解决的问题的深入思考。当然，ddd 会对大家有一些技术背景要求，面向对象、函数式编程这些基本的技术需要掌握，solid ，cupid 这些好代码的原则需要知道。这些基础技能不熟悉，我们就会想要基于某个特定编程语言去学 ddd ，其实这是本末倒置了。

@yule111222

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

不过将 smart domain 和直接引用的聚合结合起来用，也是值得尝试的。事实上，我在文章中也提到可以尝试这样做。

@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 是有很大作用的。

@yule111222 我一般的做法是用 TDD 来驱动复杂场景的模型设计，从而尽可能丰富领域模型，同时还顺便把测试加上了。所以，我会觉得用 TDD 可以驱动实现 DDD 。（简单场景的话，凭经验进行设计就搞定了）

打一波广告，最近刚开源了一个用于进行 ETL 开发的工具和库： https://github.com/easysql/easy_sql
有兴趣的同学可以研究一下里面的领域模型设计及测试（目前有 80%+的测试覆盖率）。

@yule111222
聚合的问题在于粒度难以把握。现在大家都倾向于用小聚合，那么多小合适呢？之前的小聚合，是不是可能由于聚合内的实体逐渐变复杂而需要拆分呢？
测试更加不是一定要有聚合的理由。如果逻辑拆分合理，每一个实体应该都有自己的业务能力。测试应该针对每个实体的公开 API 来测试。如果直接对聚合上面的 API 来测试，则会把分散到各个聚合内的实体的业务逻辑一并测试到，从而导致需要覆盖的场景特别多特别复杂。

以上是个人的理解。

@yule111222 欢迎回来分享使用经验啊！

@jamel
分层架构的问题是，容易让开发人员把注意力放在分层上（导致领域模型抽象不足），而忽略了领域层建模才是 DDD 的核心。Smart Domain 可以把大家的注意力转移到领域层建模上。
就像 Eric 说的 DDD“远远不只是 ‘发现名词’，业务活动和规则如同所涉及的实体一样，都是领域的中心… 当我们的建模不再局限于寻找实体和值对象时我们才能充分吸取知识… ”。

其实，在分层架构下，对于合理的分层，现在的框架都有很好的支持，基本上都是利用框架的能力实现了。这也是应该弱化分层的理由之一。

@jamel
Smart Domain 是作者对这一 DDD 实现方式的命名。是一个新词。第一句话里面有提到。

至于文献，目前应该是没有的。其实工程实践类的专有文献一般比较少，毕竟不是科研。比如 DDD ，可能也找不到啥专门解释它的论文。有关工程实践类的书倒是不少，也许八叉后续会写本书来介绍 Smart Domain 吧。

@FrankHB
哈哈，淡定。

正如文中所说：
“ CUPID 中的 Unix 哲学主要指其最重要的一个观点：一个程序应该做一件事，并将其做好。
“ CUPID 就是从特质的角度来定义的，它尝试用一组助记词来指示好代码所具备的一组特质，并希望这组特质是最重要的特质。

当然，Unix 哲学好不好这个对个人来说可能比较主观，但是纵观现在的软件行业，Unix 使用如此之广泛，这还是能反映主流是认同的。

@horizon
文中说的确实是 TDD 。TDD 可以帮助我们用领域语言写代码和定义接口。这一点其实与 DDD 提倡的大声的建模的思想是完全一致的。文中的示例也可以印证这一点。

更多内容可以看我的其他关于对 TDD 的理解的分享：
- 从改善设计的角度理解 TDD: https://brightliao.com/2019/07/20/tdd-for-improving-design/
- 从改善设计的角度理解 TDD (2)： https://brightliao.com/2019/08/18/tdd-for-improving-design-2/

@10Buns 什么主题？

DDD 的核心指导思想是：深入研究领域，消化知识，充分沟通，然后用软件模型对问题进行深刻的抽象，最终得到一个富含知识的领域模型。DDD 的实现不在于用何种方法，而是看最后是否得到了良好的深刻的领域模型。

个人有一些之前的思考和实践经验，给大家分享一下：

代码中的领域： https://brightliao.com/2019/08/08/domain-concept-in-your-code/
用 DDD 思想来编写 Pipeline: https://brightliao.com/2020/01/05/DDD-in-pipeline-code/

要说代码质量，首先要搞清楚什么样的代码是高质量的代码。

咱们经常提的 SOLID 原则是衡量 OO 范式的代码质量的一种。

不过 SOLID 的局限性比较大。Thoughtworks 最近在技术雷达上推荐 CUPID 是另一个可参考的好代码的特质组合。

CUPID 是指：
- C: Composable ，可组合的代码
- U: Unix philosophy ，符合 Unix 哲学
- P: Predictable ，可预测的
- I: Idiomatic ，符合惯例的
- D: Domain based ，基于领域的

我前段时间结合 CUPID 原文及自己的理解，写了一篇文章分享，给大家参考下： https://brightliao.com/2022/05/24/5-properties-of-good-code-cupid/

有了什么是高质量代码的基本理解，再去看代码质量好不好，我们会发现新大陆。

@gzk329 可以的呀，我给的例子里面，没有任何 spring 的东西。

Python 的 GIL 带来的主要影响是多线程执行效率低。
如何在实际应用中提升 python 程序的性能呢？之前做过一些尝试，总结起来，当我们想要并行加速多个计算密集型任务时，主要思路有两个：
- 用 c 语言实现，显示的释放 GIL ，之后就可以利用线程加速了
- 改用多进程来加速，避免了 GIL 问题

详细的例子，可以参考我之前的一篇总结文章： https://brightliao.com/2019/07/25/ways-to-improve-python-perf/

三个步骤：
1. 依赖都通过构造器参数传入
2. 直接 new 出对象来，依赖对象通过 mock 创建
3. 写测试时，mock 依赖对象的方法调用

你可能需要提前学习一下 mockito 这样的 mock 库。这里有一个例子： https://github.com/gmlove/microservice-template-spring/blob/master/src/test/java/me/bright/user/UserServiceTest.java

另一方面，如果你发现测试不好写，这通常是由于代码设计很差导致的。比如依赖太多，就是一个设计坏味道。
如何改善设计，我之前写过一篇文章，用 TDD 来改进设计： https://brightliao.com/2019/07/20/tdd-for-improving-design/ .

大数据开发最核心的能力在于对大数据技术组件有深入的了解。
楼上大家提到的 sql 开发的职责其实要想办法尽量转移给业务团队（数据分析师）。事实上，很多公司里面大部分写 sql 查数的工作实际上是 PM 或者运营完成的。

咱们做开发的，应该定义为数据工程师 /数据架构师。而做探索性数据分析的，应该定义为数据分析师 /数据科学家。这两类角色职责是非常不一样的，要求的技能也是非常不一样的。

对于公司里面的数据角色及职责，我有一些思考，给大家分享一下： https://brightliao.com/2020/11/26/data-work-roles/

ubuntu只适合做服务器，自己用就mac吧