ddd领域驱动设计day01笔记

领域驱动设计(ddd)学习第一天
1.架构师≠技术大牛
两者的区别在于技术大牛可能技术，架构师还需要理解业务，将业务转换为技术。
技术不直接产生价值，用户也不会为技术买单，只有理解业务需求，用技术解决用户痛点，用户才会为之买单。

2业务架构师的职责有：a能够将业务转化为技术，b能合理运用技术支撑业务。
这就需要理解和梳理业务流程，理解业务规则，挖掘用户痛点(获取方式可以是：和用户沟通)
如何成为优秀的架构师？（也可理解成业务架构师）
用技术形成我们的功能，形成我们的产品和解决方案，解决用户痛点，用户才会为之买单，给团队带来价值。
学习业务领域知识，理解和挖掘业务痛点，通过技术手段把业务落地

如果只懂技术不懂业务，业务就是成为你成长的天花板。就不能成为优秀的架构师

合理的运用技术，倾向新技术

ddd为什么开始流行？
  可以对微服务团队来进行设计
  可以用来驱动建设中台

ddd主要应用于复杂系统，系统越复杂，应用效果越好实际帮助越大。如果系统不复杂应用ddd反而会显得麻烦。
原来不流行是因为系统还不复杂。

为什么需要ddd？
   a.在新项目的开发，   更关注的是开发速度
      用ddd做新项目， 需要把业务领域分析转化为业务领域模型，在此基础上再转换为数据库设计和程序设计(包括充血模型和贫血模型)，
                    此时并不占优势，
                    
                    
   b.在老项目的维护，   
   c.在技术架构演化中起的作用
   不断的添加代码，系统规模越来越大，越来越复杂，当我们的系统变得越来越复杂的时候，我们还能像最初的那个状态能够快速更新和迭代吗？就不行了
   更新迭代速度越来越慢，跟不上市场变化。系统越来越复杂，对系统就想不清楚了。
   那么这时候就希望通过ddd把我们的系统进行抽象，抽象后在复杂的业务系统中才能想的清楚我们的设计，才能做出正确的设计，
   因此， 降低维护成本，提高设计质量，只有在高质量的代码基础下，才能实现快速交付，才能跟得上激烈的竞争
   （抽象我们的需求，通过ddd在不断变更的需求时能够快速迭代）
   不仅如此，我们还要面对另外的压力，我们的技术在快速更迭，特别是最近十年，开始是互联网，接着是大数据，5g，物联网
   sssh-》spring boot--》？？
   因为技术在不断升级，需要考虑到 在架构调整时成本更低，如何实现技术和架构解耦？
     业务领域更新我们的业务领域层，  技术更新 更新技术平台
     微服务的概念：通过微服务和跨功能的团队  把我们拆成n个敏捷团队，对应多个微服务，每个团队维护自己的微服务
                这里的关键是如何用微服务拆分复杂的系统，拆分的边界在哪里？ （必须从业务角度去划分，分析，建模，在此基础上拆分才能实现1个变更 只改1个微服务，解耦的目的）

      总结： 微服务的拆分是基于领域驱动设计ddd，真正落地才能降低维护成本。

事件风暴：event storming
  基于工作坊的实践方法，可以快速发现业务领域中的正在发生的事件，知道领域建模以及程序开发。
  基本思想是把软件开发人员和领域专家集中到一起互相学习讨论，类似头脑风暴
事件即事实Event as Fact
   领域事件即领域中发生的事实fact
   在真实世界中，当满足某个条件时会触发某事件，做某事
 事实:指已经发生过的事件
    这些事实是客观存在的已经发生的，分析时必须考虑到。可以保存到db，即信息就是一组事实。
事件风暴会议：  
   以完成领域模型为目标，参加者为软件开发人员和领域专家
   以讨论领域事件为开始，从前往后梳理，确保覆盖所有领域事件。
   项目组成员不断增加各种命令和事件，进而思考与之相关的资源，外部系统和事件
   识别模型中可能的聚合及其聚合根
   将模型分配到各个限界上下文在，构建上下文地图