“ 在光速交给软件功用特性的时分，研制人员一般挑选不去全局考虑便动手完成，缺乏周边人员对齐，没有对利益相关者进行充分的访谈就开工了。而用例其实是规划的起点，假如连体系用例都不清楚，又何谈完成的是个正确的体系呢。而在我作业的进程中，有的高级工程师对用例2字都未听说过，或许挑选在心里过一遍用例，而不是边考虑边画出来。那么是时分讲讲用例的重要性，以及为何必定要把它画出来了。 ”
以下大部分来自于我的读书笔记，以及个人考虑总结。
事务逻辑
什么是事务逻辑？程序中真正用于赚钱或省钱的进程，无论是计算机履行的进程仍是人工履行（我以为能够总结为直接发明价值的，而非高可靠，安全，韧性等）。例如银行贷款，让计算机计算利息，仍是人用计算器计算不重要。要害事务逻辑一般需求处理数据。这些便是要害事务数据。由于逻辑和数据严密相关，因而能够放在一个方针处理，即事务实体
用例
有的事务逻辑必需求自动化，而不能靠人工履行，即只要作为自动化的一部分才有意义。实质是关于怎么操作一个自动化自动的描绘，它界说了：
- 用户输入
- 得到的输出
- 发生输出所需求采纳的处理步骤
如上所述，用例操控着事务实体之间的交互方法。
- 用例不应描绘用户界面，即不描绘用户和体系间接口，输入流和输出流。
- 事务实体不知道哪个用例在操控他们（依靠反转原则DIP），底层的用例需求了解高层实体
比方
原始需求：
运维团队需求高效管控账号，需求将账号的恳求自动化，削减人工的参与以提升作业效率。
另一方面研制需求账号登录操控台查看资源，也需求用户密码凭证以让程序操控资源
用户故事示例：
经过用户访谈，提炼用户故事等手法，将上述内容转化为用例视图，我们看下采访后总结的用户故事
- 作为运维人员，需求操控他人web console的运用权限，仅赋予研制只读权限，以保证资源的安全
- 作为研制人员，需求创建暂时账号，以登录到web console进行问题定位和跟踪
- 作为研制人员，需求恳求账号，以装备给程序运用，操作体系的API
用例视图示例：
用例对架构规划和事务打开的支撑
什么是软件架构：
软件架构规划的主要方针是支撑软件体系的全生命周期，规划杰出的架构能够让体系便于了解、易于修正、便利保护，并且能轻松布置。软件架构的终极方针便是最大化程序员的生产力，最小化体系的总运营本钱。你需求考虑这些作业
- 开发
- 布置
- 运转：架构规划的影响比较小（架构掌控不了代码履行效率），一般都能够经过增加硬件处理（短期，后期根据事务驱动再优化），由于硬件比人力便宜，根据投入产出比，所以才优先把优化重心放在别处。即使如此，架构应该让开发对体系的运转进程一望而知，即用例，功用，必备行为，简化他们对体系的了解，为的是为开发和保护供给协助
- 设备无关性：满意开闭原则，高层战略与底层完成细节分离
- 保护：本钱最高，探秘本钱是找到新增功用和修正问题的最佳方法和方位。危险本钱是上述修正时，总是衍生新的问题。架构的目的是降低两部分本钱
软件至于硬件最大的不同是什么？是不断地，快速的改变
软件架构有必要支撑以下几点（独立性）：
- 体系的用例：架构有必要能支撑其自身的规划意图，架构有必要为其用例供给支撑，因而这是架构师首要重视的问题
- 体系的运转：假如体系每秒处理1000个恳求，架构的规划就有必要能支撑这种级别的吞吐和响应时刻
- 体系的保护
- 体系的开发：康威定律任何一个安排在规划体系时，往往都会复制出一个与该安排内沟通结构相同的体系。这是由于团队要独立的完成作业，所以需求阻隔杰出，可独立开发的组件。
- 体系的布置：便捷性，不应依靠成堆的脚本和装备
保存可选项：
- 完成以上的平衡很困难，比方我们无法预知体系的一切用例，运转条件，开发团队的结构，或许体系的布置要求。即使提早了解，跟着演进，需求会不断发生改变。即方针是含糊多变的。
- 采用一些原则能够有助于处理平衡问题。将体系划分为阻隔杰出的组件，尽可能的为未来保存尽可能多的可选项
用例解耦：
按层解耦是水平切分，用例则是垂直切分。所以UI，事务逻辑，数据库等需求依照用例进行解耦。依照改变原因的不同进行垂直切分，就能够持续的加入新的用例，而不影响老的
解耦的形式：
- 一切这些解耦对架构方针“体系运转”的意义：
-
- 分层解耦能够让组件在不同服务器布置（服务数据库的分层阻隔，这有点像SOA，即面向服务的架构）
- 按用例，比方不同吞吐的用例能够分隔，高吞吐，低吞吐，那么对带宽不同诉求的组件也能够分隔布置在多个服务器上
- 总归按用例解耦有利于体系的运转（其实这便是微服务）
开发和布置的独立性：
当你根据用例和水平分层解耦后，天然就支撑了独立的开发互不搅扰
消除重复的代码前要辨明真假重复：
- 真重复：每次改变都有必要应用到一切副本
- 假重复：不同的演进途径，包括改变理由，迭代节奏
因而当我们计划兼并看似相同的用例时，必定要谨慎否则将来拆分会更难。总归不要由于为了削减重复代码而兼并用例。同理，当水平分层时可能看到数据库结构或许API接口相似就要兼并。必定要考虑演进途径
再谈解耦形式：
- 用例分层的方法许多，比方
-
- 源码解耦（单体架构）：模块依靠联系，一个模块改变不会导致其他模块改变
- 二进制解耦（布置）：可能是jar，ddl，Gem，同享库，只是可独立布置的单元
- 履行单元解耦（微服务架构）：网络通信
- 项目初期难以承认哪种合适自己，乃至跟着项目的老练，所谓最合适的形式会呈现改变
- 将体系解耦推行到“一旦有需求就能够随时转变为服务的程度即可”，这让体系尽量长时刻地保持单体结构，以便尽可能保存可选项
- 因而做到源码解耦就够了，跟着项目开展能够随时快速拆分。
- 规划杰出的架构能答应从单体架构开始，逐渐演进为独立的单元，乃至微服务，也答应回退到单体架构。
可悲的故事
- 从纯客户端转型BS架构，技能满脑子的怎么构建大规模服务器集群，选型了三层的“架构”（不是真正的架构，只是一种三层布置拓扑，这也是灾难的根因），那么UI，中间件，数据库都能够分别布置了，假设要添加一个字段，每个层都要改。结果是开发期根本没有大型服务器可用，也没能出售一个需求大规模服务器的体系。一切文件都跑在一台服务器上，保护本钱却很高。—草率的决议无谓的将开发本钱放大数倍
- 一个办理租赁车队的本地事务，找来的新架构师以为运作这个小小的事务需求企业级的面向服务的“架构”。假如想在出售记录添加一个联系人要经过复杂的处理进程，并且了测试这个复杂的进程，要运转音讯总线等一些列根底服务。— 太草率的采用SOA体系的东西，许多人力耗费在完成SOA架构自身
成功的故事
坚信产品不应该让用户下载超越一个jar的文件，称为“下载即可履行”这一条规则就辅导了之后的许多决议计划。
- 决议计划1: 自研web服务器，没有运用开源的，由于编写一个基本功用的web服务器十分简略，且延迟了技能决议计划
- 决议计划2: 避免考虑数据库，采用数据库无关的规划，只需求接口屏蔽。完成内存数据存储哈希表。当体系需求持久化，再次考虑是否用mysql，最终以为哈希表写入文件更简略，精力持续放在开发新功用上。三个月后得出了一个结论，文件存储就满足好了，彻底不需求mysql（削减mysql的引进这就削减了许多的保护本钱，表结构，三方件，密码办理，查询问题，数据库服务器，可靠性等与事务价值没有直接联系的本钱）。直到有一天一个客户自己需求将数据写入mysql，他用了一天就完成了mysql存储。软件包分发后，没人实际用到mysql，连写这个mysql完成的客户都没有。
在前期，他们在事务逻辑和数据库间画了一条边界线，避免了事务逻辑对数据库发生依靠，运用文件体系做实验，反倒发现是更好的方案，而这也不会造成运用mysql的障碍。即经过划清边界，推迟和拖延细节性的决议计划。以节省许多时刻、避免许多问题。这便是助益
架构规划的主题：
A use case driven approach中的观念：体系架构应该为用例供给支撑。架构的规划图应该凸显用例。
架构规划和技能手法，结构无关，他们都是手法。而不是架构规划中包含的内容。
架构规划的核心方针：
围绕用例打开规划，脱离结构，履行环境等要素描绘用例。在确保用例需求的前提下，尽可能保存自由的技能选型。
结构不是信条：
挑选结构要考虑怎么保护自己（便是用例，团队等等，不要绑定到结构上），保持对用例重视，不要被结构主导规划
用例对单元测试的价值：
针对用例进行单元测试
总结
能够看到用例能够成为你后续许多架构决议计划的重要根据。是否应该用SOA架构，仍是微服务架构仍是单体架构？
用例的另一个价值
新来的程序员是否能从规划中一眼就看出来体系称号？新人也应该先了解体系的用例，而不是技能完成。先不要考虑技能细节，今后再决议应该怎么做。
原文链接mp.weixin.qq.com/s?__biz=Mzg…
