先说结论
搞微服务架构不晓得DDD的,项目实际落地的时候很容易会跑偏.
微服务相关的内容看多的时候,或多或少见过DDD这个概念.它不是无关紧要的,而是必不可少的.
如果一个系统的架构不能帮助一线的员工解决业务上的困难,那么,它是难以落地的.
架构很重要,但不是真空存在的
谈起微服务架构,服务治理,流量控制,全栈监控等等.内容实在很多,但这些只是基础架构.
如果你有听说过康威定律,就会知道,系统的架构不能脱离组织的架构,服务的拆分不能脱离实际的业务.
DDD用于指导服务拆分
DDD的战略设计部分,如核心域,上下文映射图等,恰恰就是指导服务拆分的良药.
核心域
核心域与子域的寻找能帮助你定位关键业务,区分那些服务适合外包,那些必须自己做.
上下文映射图
上下文映射图目的在于建立服务与服务之间的地图,从组织的角度去看待服务之间上下游的关系.
有了上下文映射图,就知道如何去服务拆分,每一个限界上下文就是一个微服务.
事件风暴
上下文映射图的困难在于寻找服务的边界,有边界的上下文才叫限界上下文.
定义正确的上下文映射图是困难的,幸运的是,业界提供了一种叫事件风暴的实践方法来降低困难度.
事件风暴是一种建模的方法,是一种反向的思考方式,从寻找关键业务事件结果为起点,一步步推论出上下文映射图.
