关于软件:该重视软件方法了实现利润-需求-设计

本文篇幅有些长，然而相比浏览各类书籍，而后了解和排汇，会大大节俭很多工夫，对于一些书中难以了解的局部做了改良，帮忙更好的了解。可能浏览本文须要一些软件办法的基础知识，能力更好了解和排汇，甚至提出反馈倡议。心愿文本对大家有帮忙，当然这须要使用好“只字不差浏览”和“只字不差了解”。

“系统性地输入式学习”，最大的受益者是本人，其次是“只字不差浏览”和“只字不差了解”的你。为什么：“利润 = 需要 – 设计”

• 先说需要：一种是“假需要”，一种是“有需要”。假需要做得多，企业成本增加。有需要并非肯定是外围价值，通过软件办法的剖析思路和工具从“有需要”中找到“真需要”，晋升软件好卖带来营收增长（价值需要带来营收）。
• 再说设计：指的是用一系列软件办法剖析业务流程和规定，产出需要剖析，做好架构设计，晋升软件系统的维护性和扩展性，进而晋升软件生命周期各个环节的效率和品质，降低成本（好的设计降低成本）。

1. 背景是什么？

不晓得你有没有发现，当下软件行业的工程师在业务形象与形象、领域建模、架构设计等能力上仿佛并没有因为业务疾速倒退，及技术框架、中间件、分布式等技术倒退成熟，带来相干的能力的积攒和积淀，反而在退化或隐没，甚至很多加入工作几年的同学都未曾应用过软件办法中的一些办法。

而软件办法随着企业规模变大，重要性其实应该被逐渐晋升才对，但理论恰恰相反，越来越不器重，而且需要越来越多，设计越来越失落，零碎扩展性和维护性越来越差，用户产品越来越简单。

记得刚加入工作头几年，我的项目一旦立项，架构设计会作为重要且紧急的要害里程碑工作，经验几轮评审和批改才进入开发，而且在旁边听前辈探讨和评审也是受益匪浅，浓浓的技术气氛推着本人也去学习。然而随着互联网疾速倒退及麻利迭代的风行，人们慢慢漠视了软件办法（麻利迭代并未要求漠视设计，而是在执行时因为人的起因不再器重，缓缓地不再谈及软件办法）。而且，平时常常听到重构零碎，然而每年都在重构，这是提高，还是退化，我认为是退化，这值得咱们反思。

能力的退化、气氛的缺失和有效的重构，是总结本文的背景，心愿在不久的未来越来越多的工程师熟练掌握软件办法中的相干办法和工具。

2. 什么是软件办法？

来自百度百科的定义，软件办法是指在软件开发过程中，从软件需要剖析、软件设计、软件编码、软件维护等环节中，采纳适宜的办法解决软件开发中的问题，实现高效的开发，以满足用户的需要。

我本人对“软件办法”了解，从业务到软件开发的一系列分析方法和工具，帮忙咱们将简单的业务知识、架构常识转变为团队中人人可能了解和上手的对立语言，并借助诸如 UML 工具产出具体的设计图。从而更加系统化、规范化地进行软件开发，确保软件系统的可维护性、可靠性和可扩展性。

然而，软件办法长成啥样？

比方你学会了设计准则和设计模式，能够说你把握了设计办法；比方你学会了为业务构建畛域模型，能够说你学会了领域建模办法；比方你学会了通过业务用例和业务时序定义组织提供的价值和组织内如何协同，能够说你把握了业务建模办法。

设计办法、领域建模办法、业务建模办法等办法的死记硬背，组成一个残缺的软件办法。大部分人能够较好把握设计办法，然而掌握业务建模和领域建模办法的人比拟少。

3. 为什么软件办法被忽视？

因为软件办法中最外围的能力，比方业务建模和领域建模能力，看起来对实现代码开发如同没有帮忙，同时把握它又有肯定的挑战，导致没有失去足够多的人器重。当然还有另外 2 个起因：

• 只重技术不重业务，只是用代码实现业务零碎，并未思考业务扩展性、维护性等。
• 业务和领域建模是种手艺，凡是手艺都须要在实践中一直经验磨炼。

4. 软件办法的重要性？

一个好的软件产品，离不开对业务的了解和形象，作为技术人员，先要对业务充沛了解，并将业务知识做形象，能力将业务了解和形象转换成更好的软件设计，这是技术人员能力倒退十分重要的步骤及好的软件系统的前置条件。

而且软件办法技能的熟练度晋升，会带来团队和集体整体交付品质和效率的进步，集体的价值和影响力也会越来越好，职业倒退门路越清晰。

本文篇幅有些长，然而相比浏览各类书籍，而后了解和排汇，会大大节俭很多工夫，况且通过本人的总结输入，对于一些书中难以了解的局部做了改良，帮忙更好的了解。可能浏览本文须要一些软件办法的基础知识，能力更好了解和排汇，甚至提出反馈倡议。

最初，心愿文本对大家有帮忙，当然，若想真的有帮忙，须要使用好“只字不差浏览”和“只字不差了解”。若总结中有谬误或不合理的中央，欢送留评指出，不胜感激。

一、软件办法概要

产品和研发在进入具体开发之前，我认为须要思考分明如下 3 个问题：（1）首先，须要理解需要会不会变动；（2）其次，无论需要变与不变，要晓得晋升“好卖”和“降本”的办法；（3）最初，实际建模办法开掘被钻研组织提供的价值，升高实现老本。

1. 需要会不会变动

人类或组织相干需要从过来到古代大部分不会发生变化，在未来大概率也不会变动，比方存 / 取钱、吃饭、看病、出行、看戏等。然而随着技术倒退和资源逐步富余，很多需要会一直呈现或产生演进，比方买货色不要出门、看戏到看电影 / 短视频、吃饭点菜时心愿不要期待。无论需要变与不变，实现需求的形式会随着技术倒退而逐渐变动，这是毋庸置疑的。

比方，以“取钱买商品”需要为例，这个需要从现代到当初都没有发生变化，只是需要的实现形式变得更高效了。10 几年前，咱们要从家里先坐车去银行取完钱，而后坐车去商场买货色，最初从商场拿着商品坐车回家，一天下来将人肉这个大的物流一直移动，人累效率又低。当初能够间接在淘宝上买商品，而后网上支付，最初由物流公司把货物寄到你家里，人肉这个物流能够做到足不出户。

而且，随着技术倒退，原先因为资源和技术受限，很多需要没法得以实现，或者需要体现形式繁多。采纳建模思维，能够更高效和高质量挖掘出需要的价值，进而通过付出心血和致力取得竞争劣势和老本升高。

比方，以“餐馆点菜”需要为例，从现代到挪动互联网之前，你每次去餐馆吃饭，服务员会给你拿一张菜单过去，而后你边点他边写，遇到人多的时候，服务员基本来不及招呼你，你要过良久能力实现点菜，上菜就更慢了。然而随着互联网遍及及智能手机的呈现，基于二维码扫码点餐大大晋升了餐馆效率及升高了人力老本，也晋升食客的生产体验。

2. 晋升“好卖”和“降本”的建模办法

任何一家企业都不得不器重的公式：“利润 = 支出 – 老本”。作为软件行业的产品和技术人员来说，咱们演进下公式：“利润 = 需要 – 设计”。通过开掘需要价值晋升产品好卖，做好软件工程的设计降低成本，进而晋升利润。

建模技能的无效使用会决定需要的价值、决定软件工程设计的品质。然而，什么是建模？

建模的实质：总结经验的过程，将经验总结为办法和工具。

以人的大脑为例，通过学习、做我的项目积攒教训、听分享、做交换等动作实现大量的信息输出之后，大脑会实现一轮建模，并总结出一些办法和模型，变成大脑的模型之一，模型越多集体能力越强，而后在下次本人遇到相似问题时，可能基于模型给出更好的办法。

放在软件开发上，建模是软件生命周期各个阶段的模型组合，包含业务建模、需要剖析、领域建模和软件设计。每一个建模技能细节的晋升，可能更好开掘到产品价值或升高研发老本，晋升产品“卖相”，及晋升架构的品质属性（如扩展性、可维护性、安全性等），这些都会带来“利润”晋升。

3. 实际建模办法开掘价值和降低成本

以“人”零碎为例，人会走路，吃饭，谈话，跳跃，还会拉马车、搬砖、讲笑话等，然而咱们人这套零碎并没有走路子系统、吃饭子系统、谈话子系统、跳跃子系统。反而是呼吸子系统、消化子系统、神经子系统、血液循环子系统。人体的每个子系统相互协同实现走路、吃饭、谈话、跳跃等外在性能体现，并为其余组织提供价值，比方为房地产提供搬砖价值，为小朋友讲三国演义（凯叔讲故事）。

从下面的例子咱们能够学习到，实现产品不仅仅是简略的把外在性能体现当中需要，而后变成一个个子系统。正当的形式是：钻研组织对外提供的价值、为了实现组织对外提供的价值，组织内须要开发什么零碎、不同的零碎如何合作及用什么样的技术实现更好的产品体验和性能体现。

以下以银行为例，按程序践行建模的 4 个办法，因为无银行教训，银行零碎的理论状况必定和下图有出入。

通过表格进一步了解上图中的业务建模、需要剖析、领域建模和软件设计的职责。

依照业务建模、需要剖析、领域建模和软件设计对组织进行建模剖析，能够强制咱们高质量思考，产出高质量的设计升高开发成本和保护老本，进而产出“更好卖”的产品。

二、业务建模

业务建模外围是找到“被钻研的组织”向“其余组织”提供的价值，个别称其余组织为用户 / 客户，但用户 / 客户过于泛化。当然，在面向社媒 / 股东等，能够说咱们有多少用户，然而产品和技术在探讨具体的需要细节时，须要从泛化到具体。

如何从泛化到具体，外围是用老大和涉众来代替其余组织。老大是为软件付费的人（或是最外围的用户），涉众是除老大之外相干的人，或者老大就是涉众里最重要的人。软件开发时优先满足老大需要，而后是满足涉众需要。

比方银行的涉众是家里有储蓄的人和有贷款需要的企业，银行通过肯定的利息吸纳涉众的储蓄，而后以更高的利息贷款给企业，这就是银行的商业模式，各种涉众的需要都失去了满足。

业务建模采纳最外围的 2 个模型，别离是业务用例和业务时序。

业务用例示意被钻研组织对外提供的价值，业务时序示意被钻研组织外部各个系统如何相互协作实现组织对外价值的提供。

还是以“软件办法 - 概要”中的银行为钻研对象（银行每个人都用过，以它为例更容易了解），来更详细描述银行业务用例和业务时序。

1. 业务用例

业务用例因素：业务执行者和业务用例。

业务用例画法：用照相机对准被钻研的组织，谁和这个组织有交互，谁就是业务执行者。如下示例，拿着照相机在组织边界处拍照（比方大门），谁和组织有交互，谁“可能”是业务执行者。为什么说可能呢？起因有些和组织有交互并不一定是业务执行者，比方来问路的人，纳凉的人，在组织内工作的人等。

以银行为例，储户来银行存款，企业来银行贷款，储户和企业都是银行这个组织的业务执行者。然而银行里的职工尽管也来银行，但他们只是银行这个组织里的业务工人，并不是业务执行者。然而，如果钻研的组织是银行里的某个子系统，比方点钞机，这个点钞机的业务执行者可能是银行职员。

如下图，围绕钱流通的商业模式，现代和古代的需要没有发生变化，都有贷款，取款，转账和贷款需要。变动的中央在于名字不同，古时叫钱庄和商人，当初叫银行和企业。

然而，随着技术倒退和资源不断涌现，组织的价值在一直演进，比方当初银行相比现代的钱庄，除了根本存取款之外，还能够为企业和集体提供诸如理财、外汇、信用卡、期权等银行组织对外提供的价值。

2. 业务时序

业务时序画法：业务时序中包含业务工人和业务实体，通过业务工人和业务时序的互相协同单干，实现被钻研组织对外价值的提供。业务工人（圆圈中有个君子）和业务实体（圆圈 + 下划线）示意形式见下图。要特地留神，业务实体的形象级别要统一，比方零碎和表构造都呈现在业务实体中，必定呈现了形象级别不统一的状况。

以“银行取款业务用例”为例，先画出银行晚期的业务时序图，而后画“点钞机 ” 呈现的改良业务时序图、最初画 ”ATM 取款机 ” 呈现的改良业务时序图。通过业务时序的一直批改（然而业务用例始终没有扭转，还是银行组织对外提供取款价值），来感触业务时序在改善组织问题、晋升用户价值体验钻研上的价值。

2.1 柜台取款

小时候家境不富裕，有点钱妈妈会把钱拿到信用社贷款赚点利息，信用社的柜员拿到钱之后要重复数几遍，有时候会拿出一张钞票对着灯光重复瞧几遍，分别是否虚实。同时家里须要用钱的时候，妈妈又会去信用社取款，当柜员把钱给到妈妈的时候，妈妈要重复数几遍，而且最放心是怕有假钞。

那个时候生产没当初这么不便，存 / 取款频率也没当初这么高，效率并非那时候的外围问题，反而钞票的数量和虚实是那时的外围问题。

2.2 点钞机呈现

于是长于钻研组织问题的人发现，钞票数量出错带来的影响：要么是储户损失，要么是银行损失。同时钞票要是辨别真假出错，银行大概率会损失更重大，因为假钞会风行。

那么，不出意外也就出意外了，有人钻研出了点钞机，一次性解决过后外围问题的：钞票数量和钞票虚实，储户和银行再也不必放心了，银行的价值和信任感被增强。于是业务时序图有了如下变动。

2.3 ATM 取款机呈现

随着银行卡的遍及和软件技术的倒退，基于存折存 / 取款逐步淡出了历史舞台，上图中的“1：服务台填写取款单”和“2.5 打印存折上的取款金额”在明天曾经逐步隐没，取而代之的是基于银行卡的存取款操作。

同时，随着互联网的倒退，人们的生产频率越来越高，存取款的频率也越来越高，意味着银行排队的人越来越多，于是长于钻研组织问题的人发现，能不能通过终端解决银行柜台不够的问题，进而为储户带来更好的体验。甚至还能够将终端装置在离储户近的中央，不用来银行就能够实现取款或贷款。于是业务序列图又有了变动。

银行组织的“取款用例”尽管经验了 3 个阶段的业务时序变动，然而对储户提供的价值没有发生变化，而且储户的体验越来越好，社会效率也越来越高。如果某家银行没有跟上业务时序中形容的变动，业务萎缩不会意外。

截止这里，能够看出业务建模中的业务用例和业务时序是一种工具，帮忙咱们找准组织对外提供的价值，而且价值十分稳固不会轻易发生变化，同时帮忙咱们找准组织外部须要改善的问题和流程，通过数字化、人工智能、终端等办法进行改善，为用户（老大和涉众）发明更好的价值，继续一直带来用户体验的变动。

三、需要剖析

在“2.3 ATM 取款机呈现”章节中提到，因为生产频次变高，来银行排队存 / 取款的人越来越多，用户存 / 取款体验越来越差，所以钻研组织在存 / 取款的体验时，提出了存 / 取款终端设备：“ATM 取款机”，进而改良了业务时序图。所以咱们需要的钻研范畴来自“2.3 ATM 全款机呈现”章节改良后的业务时序图。

需要剖析分为零碎用例和零碎用例规约。以下以 ATM 取款机为钻研对象，剖析零碎用例和零碎用例规约。

1. 零碎用例

零碎用例包含零碎执行者和零碎，零碎执行者是零碎的使用者，比方 ATM 取款机是零碎，储户是零碎执行者。

先了解零碎执行者和零碎：

• 零碎必须可能独立对外提供服务，能够是数据服务，也能够是行为服务，比方“2.3 ATM 取款机呈现”中的风控系统独立对外提供取款风控平安监测，短信零碎独立对外提供短信告诉服务。
• 零碎边界是责任边界，比方“2.3 ATM 取款机呈现”中的风控系统、短信零碎的责任齐全不一样，别离提供本人职责范畴内的服务。
• 零碎执行者和零碎要有交互，比方钻研的零碎是售票零碎，零碎执行者是售票员。如果钻研的零碎是 12316 APP，零碎执行者就不是售票员了，而是旅客。
• 零碎执行者有主执行者和辅执行者，辅执行者是被动参加，比方“2.3 ATM 取款机呈现”章节中的储蓄零碎是 ATM 取款机的辅执行者。
• 零碎执行者不肯定是人，也能够是零碎或工夫，比方定时器能够是零碎执行者，实质上是驱动零碎运行。

识别系统执行者和零碎用例办法比较简单，如果业务时序图画的十分规范和具体，零碎执行者和零碎用例都能够来自业务时序图中。以“2.3 ATM 取款机呈现”的业务时序图为例，给出 ATM 取款机的零碎用例。

因为“2.3 ATM 取款机呈现”只是画了取款业务时序，理论还可能包含查问余额、转账、贷款等业务时序流程。所以残缺的 ATM 取款机零碎用例如下：

4 个用例的主执行者都是储户，然而辅执行者没有短信零碎和风控系统，起因是钻研的零碎是 ATM 取款机。如果钻研的零碎是储蓄零碎，则储蓄零碎取款用例的辅执行者会有短信零碎。须要把钻研的零碎作为前提。

2. 零碎用例规约

一个用例一份用例规约，每份用例规约是需要细节的详细描述，包含用例名称、零碎执行者、前置条件、后置条件、涉众利益、次要流程、扩大流程、业务规定、品质要求、设计束缚等。需要形容的具体水平间接影响交付品质，用户体验。

以 ATM 取款用例为例：

受限于银行业务常识有余，以上的需要用例规约不肯定详尽，然而从前置条件、后置条件、涉众利益、次要流程、扩大流程、业务规定、品质要求、设计束缚等角度形容进去的用例，会影响从需要→研发→交付上线整个生命周期的效率和品质。

四、领域建模

DDD，中文叫畛域驱动设计，畛域能够了解为业务，比方邮件业务、银行存款业务等都是业务畛域，通知咱们要从业务登程去设计咱们的零碎，是“软件方法学”的领域，提供了一套思维模式和分析方法用于开发简单软件的系统化办法和思维。

DDD 价值是什么？能够提供零碎从 0 到 1 搭建、也能够领导零碎架构治理、还能够领导架构师造就等。如何使用 DDD，次要是学习 DDD 的“手艺”办法，比方事件风暴、聚合、值对象等。

1. 事件风暴辨认畛域名词

领域建模最外围也是最重要的一步是辨认畛域对象，只有畛域对象被辨认进去，能力基于畛域对象画出畛域对象之间的畛域关系。如何辨认畛域对象有 3 种办法，别离是：（1）仅通过聊天就能辨认，这种人是相对高手；（2）事件风暴法，通过多人合作实现；（3）通过零碎用例找对象。

为了加强协同，往往举荐事件风暴法，但须要业务、架构师、开发人员等一起，基于脑暴的形式来实现，但如果团队中，或者产 / 技之间没有造成这种能力，我倡议由懂的人来实现（比方架构师），基于实现后的畛域模型拉上相干同学分享和评审，请大家帮忙补充是否有脱漏的畛域对象，而后基于新的畛域对象再次欠缺畛域关系。

事件风暴法分为 3 个程序动作：辨认畛域事件 → 辨认命令 → 辨认畛域名词。还是以银行为例。

辨认畛域事件

畛域事件是指曾经实现或产生的事实，比方资金已转账、资金已贷款等，是实现时 + 被动语态，比方资金已贷款 = 资金被贷款，“已”示意实现。请记住，在辨认畛域事件的过程中，须要重点关注那些可能在需要文档中没有提到的畛域事件及业务规定，并把业务规定找进去进行治理。

以银行为例，包含现金、理财、贷款、信用卡、积分、短信等业务。依照“实现时 + 被动语态”来辨认畛域事件，包含资金已贷款、资金已转账、贷款已到账、资金已取款、积分已生产、资金已存定期、资金已转定期等。

其中资金已贷款和资金已存定期为什么不必一个畛域事件：资金已贷款。是因为资金已贷款和资金已转定期背地的业务逻辑不一样。比方：活期存款利息 0.3%，然而一年定期利息 1.75%，二年定期利息 2.25%，而且定期能够随时取款 / 转账，定期须要先转成定期能力取款 / 转账，而且一旦转成定期，利息只能依照定期 0.3% 计算。这些业务规定须要被独自整顿和治理起来。

下图以现金业务和贷款业务辨认对应的畛域事件及业务规定。

辨认命令

畛域事件是指曾经实现或产生的事实，而命令是引发畛域事件产生的操作，及谁执行了该命令（执行者是谁），执行该命令时做了什么查问操作（执行者→发动命令→事件产生）。

比方畛域事件“资金已转账”的命令是“转账资金”，转账人是“银行柜台”，转账人在转账资金时须要查问出“指标储户”，也能够将“指标储户”了解为被执行者。有时一个畛域事件的操作人有多个，比方除了“银行柜台”，能够是柜台经理，也能够是大堂经理在自助终端帮忙转账，甚至是储户本人，因为储户能够在手机银行转账。

以此类推，直到将所有畛域事件的命令和执行者找进去，以“现金业务”为例，辨认命令和执行者后，失去下图：

辨认畛域名词

辨认畛域名词是指从畛域事件、命令、执行者、查问对象（如存入资金之前须要登录储户账户）等上找出名词。比方畛域事件“资金已转账”的命令是“转账资金”，命中中的资金也是畛域名词，同时执行者中的“储户”、“柜员”、“柜员下级”、“指标储户”也是畛域名词，

这里要说分明：畛域名词 ≠ 畛域对象。畛域对象可能是多个畛域名词的合并，也可能畛域名词是畛域对象的一个角色，比方指标储户只是储户（畛域对象）的一个角色，储户和指标储户合并为是储户（畛域对象）。

如下图，以“现金业务”为例辨认进去的畛域名词有储户、资金、账户、指标账户、柜员、柜员经理、大堂经理等，可能还有不全，须要通过在后续畛域模型设计，及评审过程中发现和开掘。当然这些畛域名词还不是最终的畛域对象，须要对畛域名称进行合并归类、形象，比方柜员、柜员经理、大堂经理能够形象成银行职员。

下面通过便签纸产出畛域事件→命令→畛域名词的形式适宜多人协同，如果是架构师一个人的工作，能够通过表格的形式来整顿，更简略和直观，效率也更高，比方下图：

2. 了解类图 6 种 UML 关系

插入 UML 关系了解会有点突兀，然而先深刻了解类图中的 UML 关系，会在接下来的领域建模中不会受限于 UML 概念含糊，进而影响表白畛域对象之间的关系。

了解类图的 6 种 UML 关系，在后续的畛域模型、模块设计、类图等关系中都会用到，然而并不是说每种设计都须要齐全用到 6 种关系，比方模块设计可能更体现依赖关系，畛域模型更多会应用关联、泛化和聚合（其实应该是组合）关系，类图中更多应用关联、泛化和实现。

加个本人的了解：依赖、组合、聚合、泛化和实现 5 种 UML 关系都是关联关系的扩大，目标是为了让业务知识或代码设计时含意更具体，形象更清晰。比方组合表白的是整体和局部的关联关系，且局部不能脱离整体存在。

关联

示意两个类之间有分割（2 端没有箭头，能够了解为是一种双向关系，比方通过客户能够以查找到该客户的账号，通过账号能够查找到账户所属客户），其中一个类对象能够拜访另一个类对象的属性或办法，能够说是数据导航关系。关联关系用一条一般的实线示意。比方客户和账户之间的关联关系，客户能够查问本人账户中的资金。

具体的含意解读：1 个客户至多有 1 个账户（如果在银行未开号就不属于客户），最多 * 个账号。然而一个账户只能属于一个客户，不能属于多个账户，否则账户中的资金就变成了共享资金了。

依赖

示意一个类的实现依赖于另一个类，即一个类的办法中应用了另一个类的对象，表白的范畴更广。而且，关联是依赖的一种关系。依赖关系用一条带箭头的虚线示意（只有一端有箭头，是一种单向关系）。比方柜员（银行职员）接管客户转账需要时，依赖客户账号受权（提供银行卡，输出明码）能力帮忙客户实现转账。

依赖常见利用场景，可能更多呈现在模块的依赖关系，比方依据依赖倒置准则，低层模块不能依赖高层模块，比方应用层依赖畛域层，然而不能呈现畛域层依赖应用层。

组合

示意整体与局部之间的关系，整体蕴含局部对象，局部对象不能脱离整体而独立存在。组合关系用一条带实心菱形箭头的连线示意，指向整体类。比方人和四肢，没有人，四肢也没有存在价值；比方员工和员工技能，没有员工，员工技能也没有价值，所以组合的另外一种暗藏价值是用于爱护业务规定被毁坏的一种伎俩，是畛域模型中十分重要的一种关系。

什么是规定被毁坏，比方在并发场景下，（1）线程 A 查问员工小明编程技能，没有编程技能；（2）线程 B 也同时查问员工小明编程技能，也没有编程技能；（3）线程 A 增加小明编程技术，增加胜利；（4）线程 B 也开始增加小明编程技能，因为之前没有查问到，也会新增编程技能。这样导致的后果是，小明的编程技能被减少了 2 条，但业务规定要求编程技能只呈现一条。

正当的形式，是把小明的信息作为整体，不能被 2 集体同时操作，也就是说把小明作为整体锁起来，只有小明事务整体提交，并开释锁之后，其余线程才容许操作。

比方，银行零碎中，现金账户和定期账户、定期账户是整体和局部的关系，现金账户中的资金别离定期、定期。

聚合

示意整体与局部之间的关系，整体能够蕴含多个局部对象。聚合关系用一条带空心菱形箭头的连线示意，指向整体类。比方，人和汽车、电脑的关系，汽车和电脑是我的财产，我也能够转移财产给家人用，甚至卖掉（组合中的人和四肢关系，四肢没法转移，甚至卖掉）。

比方，银行职员的业务后果蕴含哪些？能够用聚合示意，比方包含集体客户和企业客户，因为如果职员到职了，集体和企业客户都能够转交个接手的银行职员跟进。

畛域模型常常提到聚合，但却用实心菱形箭头连线示意，能够说表白的是组合，关系却用了聚合关系表白。

泛化

泛化用空心箭头示意，是一种统称或分类关系，比方生物能够分为动物和动物，动物又能够分为哺乳动物和爬行动物。或者哺乳动物和爬行动物统称为动物。也就是说，泛化进去的对象是一种更形象的概念，可能表白不同对象间的共性和共性。

比方，哺乳动物和爬行动物共性局部是都有呼吸系统，用于呼吸氧气和排出二氧化碳；共性局部在于哺乳动物的卵类很少，少数是胎生的，而爬行动物的卵类很多，少数是卵生的。

比方，银行零碎中的账户和贷款账户，资金账户能够用泛化示意，共性局部是都须要有账号和明码验证，共性局部在于贷款账户是欠钱（贷款金额）、资金账户是储蓄（储蓄金额）。

实现

示意一个类实现了一个接口，必须实现接口中定义的所有办法。实现关系用一个空心的带箭头的虚线示意。实现关系个别呈现在代码设计的类图上，是一种面向接口编程思路。比方，电商购物反对买家在线付款，付款类型包含招商银行、工商银行、花呗等。

备注：下面的 UML 图中，有些有 +，有些没有，区别是什么？

1. 代码 UML 图：+ 在 UML 图中示意拜访权限，比方 + 示意 public，- 示意 private，没有示意包拜访权限。

2. 畛域模型 UML 图：畛域模型表白时没有必要体现代码实现时的拜访权限。

3. 建设畛域模型

事件风暴的价值是辨认出畛域名词和业务规定，是对业务的间接形容，而领域建模的价值是将畛域名词转为畛域模型，须要形象和提炼，比方把柜员，大堂经理形象成岗位，更加深刻业务实质，而不仅仅停留在外表，是 DDD 最重要的成绩积淀。建设畛域模型包含从一堆畛域名词中辨认畛域对象，梳理畛域对象之间的关系，畛域对象的要害属性，将畛域对象组成模块等。产出畛域模型有 2 个益处：

1. 将畛域常识可视化，不便日常沟通、共识。

2. 领导软件设计和编码，转换成代码和数据库。

畛域模型通常用 UML 来表白，UML 中文名称是“对立建模语言”，从名字能够看出 2 个要害信息：“对立”和“建模”。“对立”是指对立了大家沟通时的语言和名词，沟通效率高；“建模”是指办法，采纳 UML 工具能够帮忙咱们实现建模的动作。

UML 中最重要的概念包含：类和类 6 种关系（聚合、组合、泛化、实现、关联、依赖），类之间通过 6 种关系连贯产生的图，叫类图。

畛域模型中最重要的概念是实体和值对象，畛域模型中的实体能够映射为类，画畛域模型就是画实体间的类图关系，比方账户是实体。

画畛域模型的时候，一开始只须要画畛域对象的关系，且畛域对象个别用中文示意（防止画的时候就思考到我的实体就是类名），同时畛域对象的属性也能够先不体现，或者只体现外围属性帮忙了解畛域对象，毕竟咱们的目标是通过畛域模型表白业务知识。

在画畛域模型图的时候，须要辨别畛域模型是形容业务，类图是技术视角的眼帘，比方下图：

解读畛域关系图

储户 vs 客户：事件风暴中辨认进去的畛域名词是储户，这里为什么把储户改成了客户？次要是对储户做了一层概念形象，字面了解储户个别是存钱，然而去银行不仅仅是存取钱，还包含贷款，理财等，能够是集体，也能够是企业，所以对立用客户作为畛域对象（领域建模时须要把看到的景象进行形象）。

新增资金流水：事件风暴中未辨认进去资金流水畛域名词，这里为什么加上资金流水畛域对象？次要是资金会产生变动，而且资金的安全性和准确性要求十分高，须要可能追溯每笔资金动向，所以这里加上了资金流水畛域对象（事件风暴办法中可能会存在潜在看不见的畛域事件，或者用例中可能无奈看见的用例）。

资金 vs 现金账户：事件风暴中辨认进去的畛域名词是资金，这里为什么把资金改成了现金账户？次要是事件风暴阶段，咱们只思考存取款等操作，更多的是对资金操作。然而客户在银行的业务可能是现金业务，也可能是贷款业务、信用卡业务、理财业务，每个业务应该是独立的业务规定和业务流程。

操作人 vs 职员 & 账户：资金流水关联操作人，然而操作人和储户 & 职员的关系是什么，示意当初还没齐全想分明用哪种 UML 关系表白。

新增岗位、交易类型等：事件风暴中辨认进去畛域名词是柜员，柜员经理和大堂经理，然而上图中畛域名词变成了岗位，这也是画畛域对象时常常会用到的办法，须要做一层畛域名词提炼，防止间接平移。也就是说咱们眼睛看到的事物，不肯定和零碎中齐全一一映射。

关联

示意两个实体之间有分割（2 端没有箭头，能够了解为是一种双向关系），比方资金账户和资金流水是一个关联关系，每产生一笔资金流水，就会产生一次关联，所以资金账户和资金流水 1 对多的关系。

当然能够再形象，比方产生资金流水实质上是产生了一笔交易，也就是说能够形象出“交易”实体，资金账户和交易产生关联关系，资金流水和交易是聚合关系。

思考：资金和资金流水为什么不必聚合关系？资金流水无奈独立于资金。

聚合

依照 UML 关系中的聚合概念：聚合示意整体和局部关系，局部来到整体能够独立存在，比方人和汽车，尽管汽车归属我，然而我能够将汽车借给他人。同时聚合关系用一条带“空心”菱形箭头的连线示意，指向整体类。

然而在领域建模中聚合用“实心”菱形箭头示意，依照我本人的常识体现了解，用聚合表白不对，或者通过 UML 关系表白业务知识时，把组合和聚合统称为聚合，表白整体和局部关系，且局部来到整体不能独立存在。

比方上图，资金账户是整体，定期和定期是局部，资金账户总额由定期和定期组成，定期和定期有明确的归属账户，不能来到资金账户独立存在。如果独立存在，相当于钱跑到他人账户里去了。

泛化

泛化用空心箭头示意，是一种统称和分类关系，比方生物能够分为动物和动物，动物又能够分为哺乳动物和爬行动物。或者哺乳动物和爬行动物统称为动物。也就是说，泛化进去的对象是一种更形象的概念，可能表白不同对象间的共性和共性。

比方上图，账户是统称，而资金账户、贷款账户、及未画进去的信用卡账户是分类。他们之间的共性在账户中，比方账户所属人，账密。他们之间的共性局部在各自外部，比方资金账户是银行付息给储户，贷款账户是储户付息给银行。同时每一个分类的业务规定和业务流程差别较大。

思考：账户和资金账户，贷款账户为什么不必聚合关系？是否能够用聚合？

值对象

实体和值对象容易含糊，但若抓住“不可变”这个规定，就比拟容易辨别了，比方岁数 5 是一个值对象，5 放在我身上和放在其他人身上都一样，或者我儿子往年 5 岁，明年尽管 6 岁，5 还在。

值对象能够是原子的，比方数字 5。也能够是复合的，比方姓名，由姓和名组成。在畛域模型中形象值对象，次要是形象出组合值对象，或枚举类型。比方员工状态，包含实习、正式和到职，员工状态能够被定义一个值对象。

业务规定

业务规定是软件十分重要的组成一部分，规定没有被恪守，导致呈现软件 Bug 或破绽。如何更好地治理规定，简略的办法是基于零碎用例进行集中管理，按模块治理，比方下列表格：

五、软件设计

软件设计范畴十分广，比方概要设计中的物理架构、逻辑架构、数据架构、可用性、平安、高性能等。具体设计中的接口设计、表构造、类图、状态流转等。

本文是从软件办法角度学习总结，所以在软件设计章节总结过来被省略、或常常被探讨然而彼此都很难说服对方的内容进行总结。还是连续本文银行案例，因为无银行教训，可能设计细节会有出入，然而不障碍咱们通过分享和探讨逐步了解含糊局部。

我会挑以下局部进行本人知识结构的梳理，别离是状态机、充血还是贫血、肯定要聚合根吗。

状态机

通过下图读懂状态机图示表白，须要特地记住的知识点：从 A 状态转化成 B 状态的箭头直线，形容了某个「事件」产生时，恰好某个「条件」成立，通过具体「动作」，实现状态 A 到状态 B 的转化。

比方筹备「睡觉」这个事件产生，此时「灯亮」这个条件成立，通过「语音关灯」指令实现关灯，将「灯亮」状态变成了「灯灭」。

同时状态机中还有一个知识点须要记住：如果多种事件导致同一个状态产生，能够间接在指标状态中形容，比方下图中的灯灭有 3 种转化，别离是睡觉 [灯亮]/ 按下按钮、睡觉 [灯亮]/ 语音关灯、限电 [灯亮]/ 拉下总闸。

有了对状态机的了解，上面开始理解为什么状态机很重要。

畛域模型中的畛域对象有生命周期，意味着生命周期变动过程中会因为不同事件产生，带来畛域对象不同状态变动。如果状态演变流程简单且多状态，会大大增加零碎复杂度及状态准确性，如果不足状态机的无效设计，会减少代码解决的复杂度，进而带来 Bug 及用户不称心。

解决的办法就是基于状态机形容分明畛域对象状态流转的业务知识，而后用代码实现。还是以银行为例，比方畛域对象「资金」，资金有交易状态，包含资金解冻和资金失常状态。能够设计如下的状态机。

上图状态机把因为各种事件导致的状态变动集中在了资金解冻和资金失常 2 个状态中，当然也能够把各种事件都画进去体现图复杂性，然而我感觉必要性不高，会减少了解老本。

同时资金交易状态，我只定义了“资金解冻和资金失常”，理论银行的资金状态可能不是这 2 个状态，然而没关系，咱们要达成的指标：通过状态机清晰定义哪些事件导致状态变动，把这些事件用代码实现它，就能躲避很多问题。

另外，状态流转背地是简单业务知识流程，当多个畛域对象都存在状态变动，咱们要防止在一张状态机图中体现出所有的状态流转，那样起不到简化业务知识的成果，反而减少了解的难度。

比方账户有很多状态，比方开户中，解冻中，风控异样，失常等。如果把账户状态和资金状态放在一张状态机会大大增加浏览难度和了解老本。如果再加一个畛域对象的状态在一张状态机中，复杂度会再次减少。

充血还是贫血

贫血还是充血始终被争执，其中 2 个争执较多：

（1）业务逻辑放在实体对象，还是 Servie 中？
（2）实体对象是否须要依赖 Repository？不同的人实际后果不一样，谁也无奈压服谁，这也是为什么将“充血还是贫血”作为一个大节。

争执 1：业务逻辑放在实体对象，还是 Servcie 中？

贫血模型：一个畛域对象的业务逻辑实现由一个服务类和实体对象实现，实体对象蕴含畛域对象中的属性和数据，服务类中蕴含畛域对象的所有办法，负责具体的畛域逻辑解决，及长久层的调用。也能够简略了解为畛域的行为都由服务类对外裸露，如下图：

充血模型：畛域对象的业务逻辑实现同样由服务类和实体对象实现，然而实体对象不仅蕴含畛域对象中的属性和数据，还包含具体的办法，服务类仅仅面向内部裸露接口，具体的逻辑解决和长久层解决由实体对象实现，如下图：

通过下面 2 张图，看起来充血模型要优于贫血模型，因为所有逻辑都封装在畛域对象。但到底贫血模型好，还是充血模型好？争论不休。但能够确定的是，一个团队或一个零碎来说应该对立模型，不能一个零碎中既呈现贫血模型，又呈现充血模型。

当然，如果只是实践探讨，不波及代码实现，大部分人可能会同意应用充血模型，外围起因是充血模型还原了畛域模型的原貌（从模型到代码一致性），包含所有的组合，聚合对象的封装等，比方资金畛域模型，包含定期资金、定期资金、资金明细等。这些关系在畛域模型中体现的是业务的复杂度，但如果把复杂度平移到代码中，可能会减少代码的复杂度，这也是为什么，很多代码反而是贫血模型，而不是充血模型的关键所在。

当然，事实中更多采纳贫血模型，还有另外一个起因：充血模型须要更强的畛域设计能力和对象形象能力。而贫血模型把逻辑放在 Service 中，面向过程编程，或面向步骤编程，可能更合乎咱们编写代码的思路，从第一步 … 第 N 步。

如果要问本人的抉择？基于本人的编程经验，会抉择贫血模型。次要有以下几个起因：

• 无论是实体对象，还是服务类，实质上都是对外裸露行为，下层调用者不关怀实体对象或服务类的外部实现，而且从命名上能够不便看出畛域的含意，比方 FundService 和 FundEntity。
• 服务类灵活性高，如果一个畛域对象的逻辑非常复杂，把所有畛域逻辑封装在一个实体对象里，预计实体对象会爆炸，既蕴含数据，也蕴含行为，反而给下层应用带来累赘。然而服务类能够通过职责拆分，比方拆分成资金取款服务类、资金转账操作类等，这些服务类，Repository 和实体对象独特组成了畛域模型的实现。
• 经典三层分层（Controller、Service、DAO）将畛域模型进行了切割，每一层职责清晰，也容易了解。同时因为实体对象反馈的是业务畛域的关系，这个关系并未因为分为三层被毁坏。

争执 2：实体对象是否要依赖 Repository？

对于数据的长久化存储放在哪里？也是贫血模型和充血模型的争论点，如果是业务逻辑为什么要关怀数据的长久化还是非长久化呢？如果内存足够大，是否能够间接在内存中运行呢？通过极其条件探讨理论指导的正确性，有时候也是一种办法。所以贫血模型是把数据存储从畛域模型中分离出来，变成基础设施层是一种指导思想。

畛域模型的存在不应该依赖任何技术框架，是纯正对业务的逻辑形象。然而如果应用充血模型，充血模型会依赖 Respository，那么充血模型的 Respository 操作必须只和本畛域相干，如果跨多个畛域模型的操作，就毁坏了畛域。

面向聚合根对立操作

聚合的一个次要特色是具备不变规定。而保护不变规定的前提是要做好对聚合的封装，否则，内部的对象就可能无意间毁坏聚合外部的规定。

意味着，服务类的行为入参都是聚合根，比方，以人为例，人是四肢和器官的聚合根，如果四肢或器官受伤了，必定须要把人送到医院能力做医治，不能把四肢砍下来，或者把器官割下来送到医院医治，医治之后再运回来装置下来，即使四肢和器官医治好了，然而人预计早就没命了。同样现金账户也是同样的情理，在操作定期还是定期，都须要通过现金账户这个聚合根。站在技术实现的角度，通过聚合根还可能保障事务的完整性。

聚合根的逻辑十分合乎咱们的思维模式，置信在实践层面的探讨没人会回绝“面向聚合根对立操作”的领导形式，但为什么现实情况又有这么多的争议，而且理论代码的实现往往是毁坏这个领导形式。

我认为实质起因有如下几点：

• 基于聚合根操作给代码实现带来了复杂性，每次操作聚合对象都须要通过聚合根来实现。
• DDD 思维呈现在 20 年前，过后的软件系统很多是桌面端或者单机，像互联网这种分布式系统还未风行，通过聚合根实现事务比较简单。然而分布式系统下的分布式事务下，事务的保障并非聚合根的思维就能够解决。
• 事实中对聚合对象的操作尽管没有基于聚合根，但并未毁坏“聚合根思维”，这点很多时候并未被提出来探讨过。比方，日常操作聚合对象的时候，聚合对象上都有聚合根的 ID，同时如果波及聚合对象变更之后，聚合根也要变动（反之），在 Service 中会依照面向过程编程，把聚合根也做变动。

所以，我的观点是“面向聚合根对立操作”的指导思想，是通知咱们一个聚合外部的逻辑要放弃一致性（就像事务一致性一样），每次变更聚合根（比方删除），对应的聚合对象也要变动。而不是每次都要 new 聚合根和 new 聚合对象，这样的确给代码编写带来了很多老本和复杂度，能够通过聚合根 ID 来操作对应的聚合根和聚合对象。

利用分层

畛域模型是解决业务复杂度的问题，代码是畛域模型的具体实现。能够间接从畛域模型平移到代码（比方 DDD 中提倡的聚合根对立操作），也能够采纳分层架构思维。然而，代码的实现是否要齐全从畛域模型平移过去，我本人是打个问号的？

一方面很少见到间接从畛域模型平移过去的实现，另外一方面，本人的编程习惯或 CR 看到的编程习惯，大部分还是面向过程，面向步骤的编程。所以以下给出的利用分层只是参考倡议，各自能够参考，也能够调整。然而有些准则须要失去恪守：

• 依赖倒置：有 2 个含意，别离是（1）高阶模块不能依赖低级模块，比方基础设施层不能依赖应用层；（2）依赖形象，不依赖实现，层与层之间的依赖通过形象依赖。
• 服务粒度：也有叫界线上下文，不论何种叫法，服务的拆分粒度只有拿进去探讨，必定会有不同的观点。我的观点，物理粒度无需过多探讨，须要的时候自然而然会拆分，比方并发上来了会拆分多个服务，从单体利用多分布式应用。所以咱们更偏重在逻辑粒度上，逻辑粒度能够依照聚合角度拆分，将来须要做物理拆分，能够将单体利用中的聚合拆分即可，而且因为低耦合疾速实现物理拆分。

1. 横向每一层

Adapter 层：适配层，集体不太喜爱该名字，兴许用网关更适合，负责承受来自不同设施的申请和响应，包含申请和响应之间的平安校验、登录验证等。Adapter 能够向下依赖应用层，依赖的形式遵循依赖倒置准则，通过形象 Client 二方包（接口定义和 DTO 定义），实现依赖。

应用层：向上裸露畛域对象的行为（叫办法也行），向下执行各畛域服务的编排、调用和后果封装。应用层不应该蕴含畛域的业务逻辑，是很薄的一层。同时应用层不能向上依赖 Adapter（通过 Client 接口形象裸露畛域的行为），能够向下依赖依赖畛域层和基础设施层，然而层与层之间的依赖遵循依赖倒置准则。

畛域层：畛域的业务逻辑在畛域层实现，包含畛域服务、实体、值对象等，甚至还包含 DO，这里须要阐明下我本人的观点，DAO 和 DO 等不属于基础设施的实现，只是咱们在应用基础设施时做的一个封装，应该放在畛域层。同时，畛域层还会波及到底是用充血模型和贫血模型，集体的教训更偏向于贫血模型，具体的起因参考《5.2 充血还是贫血》。畛域层是业务逻辑的内聚，势必会波及到 DB 存储，缓存提速，文件解决等，对这些基础设施的依赖遵循依赖倒置准则。

基础设施层：次要是各类基础设施，包含 DB、Cache、File 等，这些基础设施个别都会提供各自的 Client 包，畛域层基于 Client 能够实现对基础设施的调用。

2. 纵向每一列

每一列的划分基于聚合维度，比方还是以银行为例，资金是一个聚合维度、贷款是一个聚合保护、账户也是一个聚合维度，各自应该有独立的 Adapter 层、应用层、畛域层、基础设施层。然而物理构造上有可能是独立，也可能是在一个利用中。

总结

软件办法是一套思维或方法论，从业务了解到软件设计一体化的思维和办法，在思维和方法论被一直使用和实际之后，绝对应的各种能力会逐渐达到纯熟状态（比方业务用例，业务时序，UML 应用，领域建模等），自然而然可能晋升工作交付的效率和品质，职业倒退和软件品质会因而受害于软件办法背地的形象能力、架构能力、及高效高质量的交付能力失去认可和倒退。

每位技术人员应该优先偏重思维背地的能力晋升，兴许 1 年，兴许 3 年。如果像本文一样，边学习边总结边输入，撑死 1 年，快的话半年根本能够熟练掌握软件办法的思维，将来再具体实际欠缺有余和了解不到位的中央。

参考资料：

潘加宇：《软件办法 - 上》

钟敬：《手把手教你落地 DDD》

作者 | 聪安

点击立刻收费试用云产品 开启云上实际之旅！

原文链接

本文为阿里云原创内容，未经容许不得转载。