关于本章内容 1.业务建模所依据的并不是方案的好坏，而是业务的真相。 这个感觉并不绝对。如果在与业务方沟通做事件建模时，通过事件建模也复盘了现有的业务模式，并达成共识，基于新系统可以有更好的业务模式。那么我们是选择以更好的业务模式设计系统，并且刚好借这个系统上线也对现有业务方的业务模式做重组的切换；还是保留已有的业务模式，先按照已有的业务模式上线一版系统。然后随着业务方业务模式的调整，不断调整系统的业务模式去支持（业务模式的调整如果是对整个结构的重组，那对业务系统来说也会是整个系统的重组）。这两个选项没有好坏，都有各自适用的场景，所以感觉以业务真相为基础并不绝对。 举一反三 1.以数据赋能为例。原本我认知里，数据赋能应该是属于工具层面，也就是领域概念的东西。但这一章学完，感觉可以划分到业务概念的范涛，与绩效考核的模式很相似。举例：我们可以通过以往的交易数据（购买量/退货量/客诉/评价），来决策出一款商品的热度评分(绩效分数)。如果这个这个热度评分高于标准，那么就认定它可能成为爆款(潜力员工)，并增加其广告投放和采购库存倾斜运营资源(升职加薪重用)；反之如果热度评分低于标准，比如客诉多，评价差。那么就会启动多级的惩罚与整改方案(对绩效差的员工降薪与整改方案)，屡次整改考核不达标触发退供（辞退）。 为什么原本理解为是工具的领域概念而不是业务概念？因为数据赋能在原本的业务运营行为中并不包含，且一开始也只是通过技术手段埋点为业务运营提供数据帮助，属于工具。熟不知当现有的业务模式接受这个工具之后，也自动调整了自己的业务模式，将该工具的运营也囊括到了现有的业务模式当中。以至于该工具就从运营无关升级到了运营相关的业务概念。