DDD（domain drive design）

参加 DDD 大会（2017 - 12 ）

这场DDD大会真的是逼格太高，明知道自己听不懂，但是还是来找虐了，我也不知道为什么。
好吧，来的第一场就是老外的演讲，真是听完后也也没听懂他讲了些什么，真是英文不好，听不懂也看不懂(看不懂ppt)，很扎心，这是不是意味着，如果你再不上点心，学学英文听读，你就要落伍了啊！

好了，来说说今天听了之后，都听懂了写啥，其实全部都没有听懂，听的时候真不知道他们在说什么。我能记住理解的真的是冰山一角。

一，对于Alberto Brandolini 的分享： What DDD Matters Today？

• 注重业务知识的学习，团队内部的知识沉淀。
• 项目系统中注重领域驱动建模的实现
• 系统内部是可持续演进的可迭代的过程

二，为不确定性架构

• 人类最不能驾驭的就是时间

• 长颈鹿事件：基因突变适应历史环境就能生存下来

• 不懂业务的程序员（架构师）不是好的程序员

• 怎样适应变化？

  • 快速反馈
  • 重复可见（比如：在一台机器上安装一个东西，在另一台机器上也要可见可用）
  • 追求简单
  • 整洁的代码
    breaks with lemon ： 拍砖

• 考虑进化，做一个有节操的程序员

领域驱动设计与微服务：模式与实践

• microservice architecture ： 微服务架构

• 不能让所有的api 都暴露给client

• Balance model ： 从业务的角度去考虑，不关心技术如何实现

• 聚合根

  • 聚合根里的东西事必须聚合在一起
  • 尽量把模型建成值对象，而不是实体对象
  • 业务逻辑应该放在聚合根里面

• 界限上下文(Bounded Context)：
  对于一个领域概念，在界限上下文的前提下，不应该有二义性。（没有Bounded Context 就不能做DDD）
  比如：order 这个概念：

  • 如果放在选购这个领域下，那它考虑的是：价格，数量
  • DDD界限上下文（Bounded Context），用于拆分微服务

• 如何把复杂模型--------> 加单模型
  从各个角度去分析触发用户的行为：收敛点 ---------> 变化的点
• 性能大于扩展性

DDD -> 界限上下文-----> 领域--------> 问题---------> 聚合根----------> 实体

领域事件解耦： 发布--------> 订阅

其实整理一下，感觉好像还是有点儿收获的，虽然只是冰山一角，但是我相信，通过不断的积累，量变会引起质变。

最后，我有一点感想就是：

演讲或者分享session 的时候，一定要明确抛出目标和问题，完了之后能回顾和总结一下会更好的！

参加公司内部的 DDD session （2018-09-15）

这次本来是公司内部组织的邀请我司 senior 的人去参加这次的 session 的，所以我本来不是这个范围的听众，由于讲师出自我所在的项目，所以我就争取去听这场 session 了~

先说说人

这场 session 的讲师中，还有一位我司的女性，她就是我早有耳闻的一位很非常厉害的女性人物了，之前就有听人说她毕业三四年就成为了我司一大型项目的 Tech Lead , 今天我终于见识到了本人，果然让人大开眼界，感觉确实厉害，从我感觉到的是她非常稳重，从她讲东西，以及回答问题都非常精准，非常清晰，有条理，严谨，和她思考问题的角度和方式，都让我很佩服。
一直记得她说的一句话：

人无我有，人有我精

真的体会到，女孩也可以很优秀 ~

我收获了什么

其中，session 的过程就不一一赘述了。

• 电梯演讲方法论
  过程中我们借助了 电梯演讲 这样一个方法论来进行了一场 DDD 实践。
  关于电梯演讲的来历，可以自行GG~

DDD 可以视为一种方法论，可以用它的分析和梳理需求和系统，以及用它的进行拆分微服务等。

• DDD 三大原则
  • 聚焦核心领域

核心领域是是什么？
核心领域就是：人物我有，人有我精
其实就是你这个业务场景中最主要的那个领域模块，所有其它领域模块的出现都是为了支撑这个核心领域而存在

• 通过写作迭代模式探索

可能有些业务并不能一次性就完全领悟理解清楚，可以通过迭代的方式，慢慢的发现更多的需求领域场景

• 统一语言

在定义了领域模块之后，保证我们每个人对于：每个领域模块的含义，以及它的上下文，都有一致的理解，统一语言，便于沟通理解

实践 DDD

讲师给我们一道相关业务场景的题目，让我们根据这个业务场景开始实践 DDD ，最后得出领域模型

• Event streaming
  这个过程我们主要去分析、理解，和梳理这个业务场景去列出所有在再这个需求场景中发生的事件有哪些。这个时候我们需要注意的一点是可能有些事件很不重要，如果没有它也不会对在整个识别领域的过程有影响，考虑到事件的完整性也需要写上，宁多不漏。
• 命令
  找出每个事件对应的命令，也是触发这个事件的所有动作，可能一个事件对应一个命令，也可能对应好几个命令
• 识别领域
  找出所有的领域模块，将每个该领域模块以及它对应的事件放在一起
• 领域聚合
  将相似的领域模块进行合并，也就是如果它们是被同一类事件去改变和影响的，那它们就可以合并为一个领域

这个时候，会发现 刚开始我们得到的可能是几句话的需求，通过 DDD 的方式分析拆解，识别所有领域，这个需求就变得清晰了许多，包括它的业务范围，业务流程，以及核心业务，业务复杂程度，都很信息和直观。
关于这次活动具体流程请阅读

考虑进化，做一个有节操的程序员！