连接: 其他描述源
实现案例1: github链接
1，事件是对系统产生了业务上的影响的动作，相对的，如果仅仅是数据查询操作，则只会对系统产生技术上的影响，如CPU上升或者内存上升等
2，Event不一定由前面所说的某个Actor触发Command而产生，也可能是由外部系统或者某种规则自动触发Command而产生
3，某个Actor做出决策Command的前提是需要看到某些信息，或者说，支撑Actor更容易做出决策命令Command的信息。读模型一般是通过Web页面（UI/UX）来展示更多的信息，以让用户更容易做出决策
4，“部门“墙 - Organizational silos
“部门”可以是公司行政规定的部门，也可以是虚拟的组织或者团队。部门是最小职责范围划分的具象化，能让每个人更快的知道自己工作的边界并为公司做出贡献。
凡是企业，几乎必然有部门，凡是研发活动，几乎都会涉及到跨部门协作，凡是跨部门协作，必然会增加沟通成本，这种沟通成本是所有企业研发最大的隐形投入。
每个部门都会认为自己运行的良好，总是对其他部门的工作充满猜想，看不到整体，并且在事情或者项目上总是缺乏真正的对齐，只有自认为的达成一致。
- 如果相关的stakeholder不了解全貌，会更倾向于拖延而不是积极行动
- 难以达成共识，特别是跨部门之间，达成的共识更主观，并可能是错误的，会让某些人误以为是故意为之，产生隐形斗争问题
- 企业架构的混乱。如果架构师不能了解全貌，则无法做出良好的架构决策，也不知道何时应该复用企业已有的技术能力，长期的割裂会造成企业架构的混乱。
5，自组织团队与决策
如果团队无法理解整个系统，则不可能自组织，如果系统或者需求的决策不是透明的，不是去中心化的，则团队不可能自组织，比如：
- 高层集中式决定并突然公布
- 与各个stakeholders单独商量修改，并公布给其他人
6，骄傲的专家
技术人员天然就会有意无意的“鄙视”业务人员。
他们和业务人员沟通时，会不自觉或无意的暗示自己的专业能力，他们喜欢技术能力强的感觉。很多时候这会造成隐形的沟通障碍，因为沟通的一方会不时的陷入自我陶醉，而不是在真正解决业务问题。
7，软件研发就是学习
现实情况是，工程师需要花大量时间来搞明白他们到底要做什么，大多数情况下，他们都是第一次接触某个业务，这是一个学习的过程，而且不是他们擅长的技术领域。
对于工程师来说，业务学习是最容易忽略且不被看重的，甚至还有点不屑。
然而忽略业务学习，只关注技术学习，基本就是在浪费资源，是假装在解决一个很可能不会带来任何业务价值的问题，典型的现象是：没有清晰需求的情况下就开始写代码。
学习的过程肯定是累且不舒服的，如果感觉轻松，那很可能是在进行无效的学习（定义和解决一个自以为是的需求）。
学习的动力来自于探索的好奇心以及成就感（比如尝试用数据模型来表示问题空间，以便解决比原来的问题更多问题的成就感），业务建模是进行探索式业务学习的一种有效方式。
8，软件研发不仅仅是写代码
不同的人对上面这句话理解不同，从资深工程师的角度来看，写代码只占软件研发的一部分，写代码之前还有设计，还有上线与运维；
从业务的角度来看，软件研发就是写代码；
从老板的角度来看，特别是不懂技术的老板，软件研发肯定就是写代码。这里的问题是，如何让相关的人都知道全局，知道除了写代码还有其他哪些工作要做。
现实情况是，在企业软件中的整个生命周期中，维护（运维、运营）成本以及软件需求调整/增加的成本才是大头，而不是将软件开发出来上线。
如果前期需求不清晰，那么就会极大的增加后期需求调整的成本，造成整体成本的增加。如果需求没有和干系人对齐，就不能说需求是清晰的。
