公司决定要做中台有半年的时间了，对中台的认知一步步深入。以前对中台最简单的理解是“企业级能力复用”，强调“企业级”、“能力”。现在看来中台不单是企业级能力复用，“复用”指的是解决方案级复用、组件级复用，中台提供的仅仅是能力么？应该是服务！中台告诉我们如何去做业务。
与ThoughtWorks的前辈交流中收获颇丰，这里只记录一些片段，两大利器——DT和DDD。
实践过程中，用设计思维中推荐的服务蓝图来梳理业务。
按照不同场景梳理出服务蓝图后，得到跨场景的蓝图。
场景栏中每一行代表一个特定场景涉及的用户步骤和系统步骤。所谓场景产品经理关注横向，而中台产品视角由行转列，找出纵向跨场景的情况，共性和个性以备规划。
梳理服务蓝图时与外部系统交互可以当做黑盒。事件风暴会将其打开。
中台划分不基于对外的行为，而是基于内部的领域。DDD的领域划分，类似医院的科室划分，按内部的领域而非外部要求划分。DDD关注模型之间的关系，考虑了一些应用架构的东西，更多的是技术架构。
Alberto Brandolini写的《Introducing EventStorming》书中的图，是对事件风暴最清晰、完整且简单的概括。完整的阐释了从系统外部与用户的交互，到系统内（事件-策略-命令-聚合-事件）的事件传递涟漪，以及通过事件影响到读模型从而给予用户动作的响应，从而形成完整闭环的全过程。
竖线——系统内外边界线，横线——上方写模型，下方读模型。蓝色——能力，浅黄——聚合，橙色——事件；一个命令操作一个聚合（业务对象）产生一个事件。所谓原子概念可以理解为聚合（一组对象）；原子能力可以理解为操作一个对象，一次状态发生的一个变化。
事件：现实、数字世界发生的一次状态变化。数据库保存下事件的痕迹。事件的好处：可以回溯，让历史倒流。事件更关注完成了的，对系统的状态。划分依据是关不关心事件的发生，不一定持久化。（持久化是代表一个事件是否受关注的重要标志）（基于消息的操作还原到业务上是基于事件加订阅）
限界上下文与子域，如果没有NFR，是一一对应的。划分限界上下文的考虑因素：①技术栈 ② NFR考量 ③特殊的数据存储 ④ 使用方不同 ⑤生命周期不同 ⑥一致性考虑（防护层：隔离第三方的变化）
DT、DDD的意义在于保障服务划分相对靠谱、API相对靠谱、API背后的模型相对靠谱。 可惜人们总是习惯于经验式的判断，改变总是一件难事。
更多内容参考：https://insights.thoughtworks.cn/zhongtai-ddd-eventstorming/