第一章 建模和UML
建模工作流
- 业务建模--描述组织内部系统（人脑系统、电脑系统......）如何协作，使得组织可以为其他组织提供有价值的服务。新系统只不过是组织为了对外提供更好的服务，对自己的内部重新设计而购买的一个
零件。软件系统，员工-->业务实体，业务工人 - 需求--描述为了解决组织的问题，系统必须具有的表现--功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是
涉众、不能改变的契约，哪些不是，严防"做"污染"卖" - 分析--提炼为了满足功能需求，系统需要封装的
核心领域机制。 - 设计--为了满足质量需求和设计约束，核心领域机制如何映射到选定平台上实现。
以“敏捷”、“迭代”为名，放弃这些技能的修炼。
有口号无方法：
口号：我们只做最重要的需求，尽快把系统推向市场。 怎么知道哪个需求最重要？
口号：设计要分离变和不变，这样可以减少变更的成本 怎么知道哪些变哪些不变？
我们现在采用的是敏捷过程->所谓的敏捷过程就是没有过程。不应该让敏捷称为偷懒的庇护所。
为什么大多数人想要偷懒不要去做建模呢？ 因为拍脑袋要比一点点深挖下去简单的多。
第二章 业务建模之愿景
如果缺乏清晰、共享的愿景，开发人员就会兴高采烈地在错误的方向上狂奔，做的越多，浪费越多。
知道这两个（和愿景相关度最大的）功能实现难度太大做不下去了，在我看来这个项目已经没有价值，但是开发人员还乐在其中，觉得还有其他功能可以做。
开发人员 -> 提升开发技能。
没有愿景的支持，互联网时代流行的口号“我们只做最重要的需求”、“砍掉80%的功能，专注于重要的20%”将沦为空话。 如何判断哪条需求最重要呢？ 愿景就是需求排序的主要依据。
一个东西的愿景就是：东西最应该卖给谁，对他有什么好处？ “可以工作的软件”--->“可以卖的软件”
“用户满意的就是好产品”->谁是用户？凭什么人家满意？
定位目标人群：
一款聊天软件，目标人群定位为“聊天人群”；
可乐卖给谁，目标人群定位为“消费者”；
正确而无用的废话
以开餐馆为例：如果问目标客户是什么人，直接回答吃饭的人或饿肚子的人没有任何增值作用，不能帮助餐馆做出更好卖的菜品。要离开“吃饭”这个功能来定位，例如：定位为政府公务员、IT公司程序员、工地民工等等。这三种不同的目标人群，带来的餐馆风格是不一样的。
开发团队领导不是客户
开发人员还有一个偷懒的庇护所--客户就是我们开发团队的领导，因为领导让我做什么我就做什么。
这个答案来的太容易了，不需要思考；这样的答案对做出好卖的产品没有帮助。这个时候，还是要进一步揣摩领导心中的目标客户是什么样子，而不是简单的把自家领导当成客户。自己领导不是客户，他是决定客户的人。
假如有一台机器，只要对着开发机说清楚软件的功能和性能，就能生成所需软件并部署好。
改进目标是“系统改善组织行为的指标”，而不是“系统能做某事”（系统的功能）。
| 像目标的表示 | 不想目标的表述 |
|---|---|
| 提高回访订单转化率 | 建立一个CRM系统 |
| 减少每张处理订单需要的人力 | 提供自助下单功能 |
| 缩短评估贷款风险的周期 | 能够对贷款申请作风险评估 |
| 缩短评估贷款风险的周期 | 能够对贷款申请作风险评估 |
一个改进目标可能会带来系统的多个功能，一个系统功能可能覆盖了多个改进目标。
第三章 业务建模之业务用例图
有了愿景，我们知道客户对他所代表的组织现状的某些指标不满意。接下来就可以研究组织，弄清楚到底是组织的哪些环节造成了这些指标比较差，这就是业务建模(business modeling)的主要内容。
"业务" --> "核心域知识"
对于软件开发来说，业务建模的目的是为了得到待引进软件系统的需求。
开发团队经常发现需求"容易变化"。根源之一是需求来路不正，没有把系统当做一个零件放在组织中来看，靠拍脑袋得出的需求，导致得到的系统需求是错的。系统投入使用后，发现和组织的其他零件格格不入，自然要改。"需求变化剧烈"是一个假象，真正的需求没有变，只不过一开始得到的需求时假的。
业务执行者(Business Actor)
以某组织为研究对象，在该组织之外和该组织交互的组织（人群或机构）就是该组织的执行者。因为研究对象是一个组织，所以叫业务执行者。
以银行为例，外部和他打交道的->储户(存钱)、企业(贷款)，这些是业务执行者。
业务工人和业务实体
组织内的人称为业务工人(Business Worker)，例如银行里面的营业员。业务执行者和业务工人的区别是，一个在组织外面，一个在组织里面，一个是组织不可替换的服务对象，一个是组织可以替换的零件。
业务工人是可以被替换的，可能会被其他业务工人替换，更有可能被业务实体(Business Entity)替换。 例如：取款机、点钞机、营业系统。
business-entity.png
责任转移的思想对识别待开发系统的需求很有帮助。开发人员说，"我在开发一个新系统"，其实说的就是"我在开发一个新的业务实体，取代现有业务工人或业务实体的一些责任"。这样，探索需求的思路就出来了--我们画好现状的序列图，然后寻找改进点，改进业务序列图。
business-seq.png
业务用例指业务执行者希望通过和所研究组织交互获得的价值。
第四章 业务建模之业务序列图
改进业务序列图
改进模式1：物流变成信息流
thing2info.png
readnews.png
目前在各领域在"物流变成信息流"方面留下的改进空间已经不多。随之而来要面对的是信息流转不通常的问题。
改进模式2：改善信息流转
改善信息流转.png
改进模式3：封装领域逻辑
封装领域逻辑.png
阿布思考法
1.假如有充足的资源去解决问题，得到一个完美的解决方案；
2.用手上现有的资源去山寨这个完美的方案。
网友评论