1、什么是系统设计，系统设计的核心是什么？
2、如何训练系统设计的思维模式？
3、有什么方法来帮助我们理解复杂的系统？
4、如何进行系统分析？
5、架构设计的本质是什么？
6、如何进行架构设计？
7、如何进行业务领域建模？
8、模型如何推导出架构设计？
9、架构设计需要遵循哪些规范？
2.关键词系统思维，系统分析，系统设计，架构元素，架构视图，架构模型，业务模型，概念模型，系统模型，分析模型，设计模型，用例驱动，领域驱动，物件，功能，物件结构，功能交互，利益，架构工具，决策选择，架构师，架构图
3.全文概要软件从业人员的成长路线大体是在管理线和技术线上形成突破，当然也有结合起来相得益彰的。而技术上的追求，架构师则是一个重要的门槛，对于刚入行的程序员可能会认为架构师就是画架构图的，诚然架构师很重要的一个职责是绘制架构图，但这只是其中一个很小的环节而已。而实际上架构也只是系统设计里面的一个重要环节，除了架构还包含了商业诉求，业务建模，系统分析，系统设计等重要领域。本文尝试从更高视角重新审视架构设计的工作，把架构设计的上升到系统设计的立体空间去探索，最终勾勒出系统设计的全域知识体系。
4.思维分析4.1系统总览人类社会活动中的不管大大小小的，简单抑或复杂的事物，总要先出现在我们的脑海里，然后再投射到现实的物理空间来。我们总是在孜孜不倦地追求美好的事物，但现实存在的问题就是，首先我们的脑袋也理解不了太过复杂的东西，其次脑海里的想象有时候也很难真实无损的映射成现实的系统，再者由于总是资源有限的，我们并没有花不完的预算。归结起来设计一个系统，或者朴素的说，做一件事情，我们需要解决以下的问题：
维度
问题
定义
性质
这件事是否合法合规？
系统风险
受众
这件事情最终谁是受益方？
系统主体
利益
这件事做完能带来什么收益？
系统价值
目标
要做一件什么样的事情？
系统定位
需求
怎样把这件事合理的列举出来？
系统建模
抽象
怎样把这件事的主线说明清楚？
系统架构
设计
选择什么工具把这件事实现出来？
系统建设
方向
这件事是否违背了我们的初衷
系统验证
在解决以上提出的问题前，首先声明我们要实现的是一个系统，而不是随意混搭的一件物品，毕竟现在讨论的不是行为艺术。那么就需要先来了解系统的定义:
系统是由一组实体和实体之间关系构成的集合，其功能大于各个实体功能之和。
系统可以分为自然系统和人工系统，但是本文特指需要人类参与的人工系统。
自然系统：
人体系统
生态系统
大气系统
水源系统
人工系统：
机械系统
电子系统
操作系统
社会系统
4.2系统演化上面谈到在系统设计流程主要是使用了分析思维和系统思维的结合，当然人类思维还有其他的运作模式，比如批判思维，创新思维和发散思维等，以此衍生的又是另外一套截然不同的方法论。下面我们主要分析系统设计过程中的思维活动。通常谈起架构师就会联想到各式各样的架构图，谈架构图就要搞清楚什么是架构设计，那么架构设计之前是什么呢？架构设计是整个系统建设的核心环节，犹如设计图纸之于建筑那么重要，那架构设计之上应该就是系统设计了。先搞清楚系统设计的定义：
系统设计是根据系统分析的结果，运用系统科学的思想和方法，设计出能最大限度满足所要求的目标系统的过程。
业务描述上节弄清楚系统的概念，也就是先把边界框定下来，那么我们要实现的无非就是以上类别的系统。自然系统是天然形成的，或者你愿意的话也可以认为是盘古开天辟地形成的，那也可以归为人为系统。我这么说的原因是尝试把视角从软件这个领域往更加宏观的方向提升，让我们暂时忘掉软件架构师这一根深蒂固的角色。
假设现在我们想登上火星，言下之意是需要借助一套设备要把人类送到火星上，大胆一点，发挥仅存那点为数不多的物理知识储备，要设计出一套系统，能够把人类送到火星。这个时候老板就是愿意出资去火星豪华7日游的金主，那么需要一个负责人来实现这趟旅程，我们姑且把这个负责人就称为登火旅行系统架构师（叫总设计师也行，不需要在意这种细节）。那么这个系统架构师的工作，就是把登陆火星的一系列需求和目标转化成为足于支撑登陆火星庞大工程的系统架构。
根据系统总览提到的问题，先一一作答。
维度
问题
方案
性质
这件事是否合法合规？
必须确认旅客人身安全
受众
这件事情最终谁是受益方？
主体是金主，参加系统建设的供应商
利益
这件事做完能带来什么收益？
美好的旅行回忆，提升人类航天水平
目标
要做一件什么样的事情？
火星旅行，把人安全送到火星再安全送回来
需求
怎样把这件事合理的列举出来？
人身安全
住的舒服
吃的美味
少花点钱
旅程快点
最好下次能大幅减少成本
全程跟拍
带回纪念品
抽象
怎样把这件事的主线说明清楚？
输出业务架构/概念架构/系统架构
设计
选择什么工具把这件事实现出来？
技术选型组合
方向
这件事是否违背了我们的初衷
不断验证测试
由于人命关天，这项工作看起来是挺复杂的，初次接到这个单子时我内心是彷徨的。但是回答了以上问题后，感觉明朗了不少，我们在完成系统性质，受众，利益和目标的分析和解答后，才能进入到系统的架构阶段。首先对以上提到的需求，我们先用动画片里面的简单画面为基础来描绘我们的设计，然后大致根据能想到的过程完成初次业务流程的描述。
业务流程画图元素：火箭，机舱，地球，火星，来回，基础功能（安全，舒适，成本）
通过以上的描述，基本涵盖了火星旅程的四个阶段：登机，航行，下机游玩，返程，这本质上跟我们平时搭个飞的去趟浪漫的土耳其也是差不多的。而在此之前我们脑海里可能还是一片混沌，沉溺在登陆火星这项浩瀚的工程而不知道从而入手。从混沌到开始有点头绪，其实无形中已经完成了一次建模，我们称为业务建模。翻回去查阅系统总览的表格，其实我们已经把需求这个维度大致列举出来了，把登陆火星的几大领域给分离开来了。那么接下来就是要把登陆火星这个项目的主线给说明清楚。
概念抽象怎样把这件事的主线说明清楚？滔滔不绝的把一件事情讲完其实反而是很难讲明白，除非这件事情本身足够非常简单的。那么就需要抓重点的来说，这个时候就需要一个叫做“概念”的工具。
概念是抽象的、普遍的想法，是充当指明实体、事件或关系的范畴或类的实体。
简单来说，概念就是用简单的一个词汇，就可以让在坐的大家都能准确无误的理解这个词汇所表达的含义。这个是语言独特的魅力，可以说有个概念这个武器，才有了人类多次工业革命的文明大爆发。有了“概念”这个工具，再对概念进行组合，会爆发出无穷的生产力。
这里穿插讲一下概念的应用，比“傅立叶级数”这个概念，我敢打*有80%的人不知道所谓何物，但是没关系，我们并不是要来科普这个概念，先根据百度百科来看看这个概念的描述：
若在整个数轴上:且等式右边级数一致收敛，则有如下关系式:一般地说，若是以为周期且在上可积的函数，则按上式计算出的称为函数(关于三角函数系)的傅里叶系数，以的傅里叶系数为系数的三角级数称为(关于三角函数系)的傅里叶级数，记作：其中，记号“”表示上式右边是左边函数的傅里叶级数先不要怕，我这么说的目的不是为了让大家搞懂什么是傅立叶级数，这里我们可以看出即使这么*畜概念也是很普通的基础概念元素组成的，比如收敛公式，比如三角函数，比如Σ求和概念，甚至像1，2，3这些阿拉伯数字。这里不得不说学数学最核心的环节就是深刻理解概念，没有之一。说回来，这里的语境就是在大家都共同理解接受这些基础概念后，经过一系列复杂组合的高级概念，也依然能够清晰严谨的表达出来，下面傅里叶级数的产生过程的动图看看就好。好了，现在我们知道了概念这个工具的重要性和功能，前面我们已经列举了登陆火星要做的事情，那么现在就需要精确简洁的把这件事给说清楚了，这个是个困难的任务，因为如果主线没有梳理清晰，后面整个工程将万劫不复。在业务建模后就是概念建模，作为架构设计的输入，这个阶段就需要对核心业务的充分理解，同时在基础性和通用性方面的功能也需要同时考虑，这个阶段需要大量的业务专家和各个领域的科学家通力协作，保证对系统的理解没有偏差。经过一系列的概念抽象和组合，最终输出登陆火星工程的架构图，这里只是用于说明登陆火星项目同样遵循这业务-概念-架构-设计的流程，不要在意架构图本身合不合理。系统落地当然这还远远不够，系统之所以复杂，就是我们对系统总有无数更多的要求，更多的功能，更好的性能，那么接下来就是对各个模块进行分析，细化，设计和实施。当然我们不会班门弄斧真的在这里去分析登陆火星的实际流程，以上这个例子虽然比较粗旷，但是基本也描绘了一个复杂系统建设的过程，也就是从需求，建模到架构的思维过程，是从最原始的登火需求一步步扩展的过程。其实我们还可以举个小一点的案例，比如一个有趣的需求“赚钱”，引申出来就是做一个能盈利商业项目架构，的有兴趣的同学可以根据这个思维模式一步一步勾画出整个流程出来，相信对这是也不错的方法，也许还真能解决些许困惑。下面演示的就是登月过程宏观层面落地的步骤。4.3架构思维架构目标一直以来我听过很多人在讲架构，有些人在做架构，但是很难讨论出一个大家都满意的定义，什么是架构师，架构师需要做哪些工作？或者说很少有往深的去思考，只知道被称为架构师说明这个人很厉害。在我毕业的时候有个同学打趣的跟我说，你们做程序的无非就是增删改查，当时我竟无言以对，当时脑海里浮现的是一系列工具的应用技巧，比如tomcat，nginx的使用，还有对业务的翻译。随着对业务的贴近和对计算机技术的进一步认识，我重新审视“这世上的系统无非就是增删改查”，这句话说对也对也不对，这句话就跟计算机软件无非就是0和1的集合，也对也不对。特别是对刚入行的人可能觉得设计离自己比较远，因为习惯了打开idea才开始考虑业务，写代码才开始思考领域模型，这是非常不好的习惯，好像如果没有在coding状态下是无法进行建模思考，这个很难，需要持久的训练才能达成设计阶段进行思考。架构设计只是系统设计里面的一个阶段，而系统设计是应用建设里面的核心环节，有一些简单的应用建设是不需要系统设计的，当然有一些复杂的应用，在能力超强的工程师团队，有足够的默契后，也可以直接进行建设。软件架构之道最核心的问题是解决复杂性的问题，并且在解决问题的过程中找到最佳的平衡点，既要简单又能满足发展。描述系统设计的本质，就是实现纵向上的时间，横向上的空间进行考虑，规划出决策路径，最终拿到目标结果。架构师眼里第一件事不是多流行的技术，多高性能的框架，或者多完善的业务模型，而应该聚焦在利益之上。对，这个可能会颠覆一些认知，当我们真正把利益放在首位后，再去考虑接下来要完成的事情，我们的工作才能称得上架构。也就是说，架构师的天职就是最大限度的实现客户的利益，这里的客户可以是市场客户，也可以是协作团队，还可以是同一个团队的项目成员。再直白的说，架构师就是负责把老板画的饼给实现了，在相当长的一段时间内保证产物有足够的利益回报。有人会说那我们做的就是公益项目，就不考虑利益，那我我补充一下，这里说的利益不止是经济收益，还有系统带来的社会价值。那么又有人会说，架构是追求利益回报，那老板的目标就是炒股发大财，请架构师你给我选几支股票吧，那我会说其实优秀的基金经理也可以称为广义上的架构师。架构过程自然在增熵，而系统架构过程其实就是减熵的过程，一个架构的诞生始于目标的确立，然后对需求的刻画，继而是落地方法的抉择。所谓条条大路通罗马，有的是一路平川而有的则是崎岖不平，那么架构过程就是不断归类合并同类项，力求最合适的决策选择来实现我们所要达成的愿望。在面对复杂业务的场景下，我们需要做出如下的思考：确定系统实体对象和预期功能抽象系统实体之间的关系，功能与实体的关系划定系统的边界和外部环境的关系预测系统带来的效果在架构过程很重要的一项任务就是识别系统的实体关系和功能关系，进而对系统效果进行预测，也就是在完一系列的分析建模工作后推导出来的系统架构需要在预测上达到我们要的效果，那么系统预测通常有如下四种方式：经验实验建模推理系统思维系统思维不等于系统化思考，与系统思维并列的可以是批判思维，分析思维，创新思维，而我们追求的是元认知，也即是认识到自己处于何种思维模式。系统思维目标：理解系统是什么预测系统的走向为决策提供知识支持系统思维首先是高效的理解分析现存的系统，对系统重构做好理论指导基础。这一节介绍了设计一个系统需要经历哪些重要的环节，并且强调了谋求利益是系统设计的核心诉求。然后通过登陆火星这项任务把一个庞大的工程变成了可理解的独立步骤，并且还有模有样的画出了架构图，体现了对业务建模到架构输出的流程。下面章节我们将会展开来介绍一套核心的方法论，如何破局系统架构设计。5.系统分析上一节谈论了系统设计的心智模型和投射到物理世界的演化规律，但前提是建立在已经具备丰富系统设计经验基础上。而在进行系统架构之前，需要先对系统分析有一定的理解，好比我们制造发动机之前，得先把发动机拆下来好好研究一番，直接上来就要设计出发动机有点像空中楼阁。本节讲提供一套基础的方法，来对现有系统进行分析，得出一些系统架构相关的推论。按照惯例需要先搞清楚系统分析的概念：系统分析，旨在研究特定系统结构中各部分的相互作用，系统的对外接口与界面，以及该系统整体的行为、功能和局限，从而为系统未来的变迁与有关决策提供参考和依据。系统分析的经常目标之一，在于改善决策过程及系统性能，以期达到系统的整体最优。大到银河系，小至原子粒子都有着特有的结构，何谓结构：结构是指在一个系统或者材料之中，互相关联的元素的排列、组织关系而系统在物质世界里面当然也遵循这样的规则，分析系统跟分析银河系也一样，需要对它的组成元素和元素之间的关系进行分析。而对系统的分解也是讲究方法的，可以参考以下总结的一些方向：体系归纳层级分解逻辑关系自顶向下自底向上由外向内由内而外5.1实体分析实体指系统物理时空存在的单元，彼此通过一定的结构形成系统，那么在分析实体之前，我们可以带着下面的问题进行分析：系统是什么？构成系统的元素有哪些？系统元素之间的结构是什么？系统的边界在哪里？系统的使用场景是什么？实体是系统的一项基础属性，是系统的物理体现或信息体现。对功能的执行起工具性作用，而描述实体通常可以使用以下工具来表达：文字描述符号描述插图插画示意图三维图透视图实体之间的关系就是结构，分析结构时需要对实体进行分解，实体可以建模为对象以及象之间的结构，进一步可以分解为小的实体，又可以聚合起来称为系统本身，对实体之间的各种结构分析则可以得出系统架构，即是把功能元素组合成物理块时所用的编排方式分析实体对实体的载体进行抽象聚类，形成对象，体现出边界用适当的层次来分解架构的实体分析关系也即是实体的结构，是对象之间存在稳定关系，有助于功能交互的执行系统实体有如下关系：空间拓扑关系连接性关系地址关系顺序关系成员关系所有权关系人际关系5.2功能分析上面一节我们了解了系统的物理基础，对组成系统的实体进行分解，分析，进而对实体的关系描述为结构，对结构抽象是得出架构的基础步骤，而系统物理基础存在的理由是为了实现我们的诉求，也即是系统的功能。毕竟万物皆有因，存在即合理，系统构建最终也是要达成我们的意愿，完成这个诉求才算是合格的架构。分析形式相对来说毕竟简单，毕竟实体是有形的便于理解，而功能则是由实体组合涌现出来的属性，功能分析过程需要跟实体不断的交互穿插。关于系统功能其实可以朴素的认为就是动宾短语的集合，功能=动词+宾语，含义就是实体状态变化的过程，就是功能的体现，具体分析下文会详细展开。功能=主体+操作+操作对象，比如嘴巴有“吃饭”功能，飞机有“搭载乘客”功能，报表平台有“展示报表”功能操作：对象经历的一种转换模式，过程设计操作数的状态变化。操作对象：操作数是一个对象，在某段时间内稳定且无条件存在，操作数不需要先于功能的执行而存在，操作数可能会由功能中的过程部分来创建，修改或消耗。总结起来，系统分析就是建立一套方法论，去分析复杂的系统，令系统不再那么难懂。6.系统设计经过了上几节的思维训练和系统逆向分析，我们也大概理解了系统设计的流程和系统架构的形成过程，本节正向介绍系统设计，包括设计工具，需求分析，模型建立，架构推导，设计规范完整的系统设计流程。系统设计，也即是设计出一套良好的系统架构，就是构建一套具备必要复杂度又不难懂的系统。下面在介绍方法轮的同时，同时会穿插一个数据平台的大致设计过程。在进入本章节系统设计前，我们先要来学习学习一个架构TOGAF：TOGAF：框架开放组体系结构框架（TheOpenGroupArchitectureFramework，缩写：TOGAF）是一个企业架构框架，它提供了一种设计，规划，实施和管理企业信息技术架构的方法。TOGAF是一种高层设计方法。它通常被建模为四个级别：业务，应用程序，数据，和技术。在TOGAF中，任何一种企业能力的建设都需要对如下四种领域进行设计，包括针对这一可持续性架构实践建设：业务架构：突出了架构治理、架构流程、架构组织结构、架构信息需求以及架构产品等方面数据架构：定义了组织中架构连续体和架构资源库的结构应用架构：描述了用于支持此可持续架构实践的功能和服务技术架构：描述了架构实践中用于支持各架构应用和企业连续体的基础设施需求和部署方式TOGAF架构框架是一组工具，可用于开发各种不同的架构：描述了一种用于根据一组构建块来定义信息系统的方法展示构建块如何组合在一起包含一组工具提供共同的词汇集合包括推荐标准列表包括可用于实现构建块的兼容产品列表企业可以通过应用企业架构开发方法（ADM）来为建设各种业务能力，然后我们再来介绍另外一种系统设计的思路。6.1设计工具工欲善其事，必先利其器。前文讲到思维分析，不同思维模式决定不同的方法论，那么在分析思维层面，人类大脑其实很难理解太过复杂的东西，这个时候就需要借助一些工具来协助思维的活动。首先第一工具当然是语言，这个不用多说，没有语言作为基础将寸步难行，单个体的时候语言用于描述系统的诉求，而多个体的时候语言则扮演着沟通的角色，但是如果语言不互通的话可能就像鸡同鸭讲。即使是同一种语言，不同的表述都会形成很大的偏差，那么就需要一种普遍认可的统一语言，在系统分析审计领域，我们首推统一建模语言（英语：UnifiedModelingLanguage，缩写UML），当然还有其他比如SYSML或者OPM，下面我们先大致介绍下UML，列出UML的核心语言元素，视图，模型和过程。核心元素参与者用例边界业务实体包分析类设计类关系组件节点核心视图静态图包括：用例图类图包图动态图包括：活动图状态图时序图协作图泳道图核心模型业务用例模型概念用例模型系统用例模型业务领域模型系统分析模型系统设计模型系统组件模型核心流程业务建模系统建模模型分析模型实施软件工具draw.ioStarUMLVisualParadigm6.2需求分析本节不打算讲需求分析师的工作流程，因为我们已经很熟悉需求分析师对需求的分析过程了，所以无需多言，在讲需求之前我们先来看看架构师需要完成的工作。架构师并不是全能的通才，无法面面俱到的了解所有细致的需求，那么架构师要做的就是简化系统的复杂度，消除业务歧义，致力于输出健壮兼容的系统架构。由于系统需求分析需要由架构师这个角色全程参与，深度理解业务，下面我们简单对架构师角色进行讨论。架构角色我们先看看传统系统设计两大核心角色的定义：系统架构师：是在信息系统研发中，负责依据需求来确定主要的技术选择、设计系统的主体框架结构，并负责搭建实施的人。系统分析师：是在信息系统研发中，负责通过需求分析确认系统的需求，并进而形成系统产品设计的人。通常他们也会涉及可行性评估、项目管理、开发前评估、需求验证等工作。传统意义的系统开发分为系统架构师和系统分析师两个角色，但是随着互联网的快速发展，如今系统建设越来越趋向两个角色结合起来，那么互联网时代架构师有如下职责：了解问题领域，消除歧义树立业务目标，抽象业务用例完成涉众分析，发现系统主要受益者划清系统边界，确立对外交互方式划分优先级别，聚焦系统核心诉求分析业务需求，输出业务模型抽象业务概念，输出概念模型推导系统架构，输出架构模型负责技术选型，完成系统落地架构师是软件开发活动中的众多角色之一，它可能是一个人、一个小组，也可能是一个团队，我们分析的是架构师这个角色，能胜任这个角色的才是架构师，那么在这个角色上能做得更加出色的就是好的架构师。以上架构师职责是整体上的描述，在细分领域有不同的分类。微软对架构师有一个分类参考，我们参考一下，他们把架构师分为4种：企业架构师EA(EnterpriseArchitect)基础结构架构师IA(InfrastructureArchitect)特定技术架构TSA(Technology-SpecificArchitect)解决方案架构师SA(SolutionArchitect)既然对架构师角色有诸多要求，那么也可以来归纳一下架构师必备的一些技能，能力模型可以参考《职业成长的逻辑模型》一文中对能力模型的描述，架构师能力要求：现有资源评估盘点及资源编排能力消除歧义分清问题主次能力业务简化描述，用例抽象思维通用市场法务市场领域基础常识业务分析架构推导能力计算机基础理论知识体系通用技术栈原理认知工具使用熟练，排查定位问题能力技术深度广度分布式高并发性能调优技能产品思维利益分析首先当然是要确立好客户，所谓客户第一，听起来很简单，如果只是单一的服务好客户，那确实不算很难。难的是如果同时存在多个业务方向的客户，而且客户直接的利益产生交集，而且存在矛盾，怎么权衡好利益分配，区分客户利益优先级，才是困难的。不忘初心这一点尤为难得，很多项目做着做着就偏离了当初的目标，这个过程我们一定要紧紧抓住系统最重要的受益者，梳理好系统众多涉众的利益分配。资源评估资源评估不仅仅是项目经理的事，而是对团队资源的评估和编排，比如某项业务技术团队中研发和数据人员的配比，决定了数据平台投入的资源范围，这要求架构师在做设计分析的时候需要充分考虑的资源的利用效率，包括人力资源和机器等资源。需求规范用户的诉求体现为需求的输出过程，不同层次分解需求得出了不同的复杂度，我们知道架构师的一项重要职责就是消除歧义，精准的把握需求来匹配用户的诉求。那么就需要一系列规范来保障需求采集的过程中不失真。下面列出了需求采集过程的一些指导原则每个软件需求是否都有唯一的标识符？每个软件需求都可以验证吗？（如果可能，是否可正规化，量化）是否对每个软件要求进行了优先排序？所有不稳定的软件要求是否都已标明？软件需求是否完整？（涵盖了所有用户要求，考虑了所有相关的输入情况）软件要求是否一致？是否明确指出了软件需求之间的重叠交叉？是否明确规定了初始系统状态？软件需求是否表达了逻辑模型，而不是实现形式？软件需求是否以结构化的方式表示为抽象层次？是否足够清楚，逻辑模型的结构软件要求是否已正式形式化？是否已证明软件需求的关键属性？所有形式化的图表材料是否都随附了充足解释性文字？是否针对项目团队缺乏经验的领域描述了探索性原型？需求描述在进行需求描述时，我们可以从多个角度来审视需求是否合理的表达出来：满足需求，能带来什么价值，符合什么利益诉求需求无法满足时，会带来什么危害，有何潜在风险需求是否紧迫，必须在什么时间段内完成多个需求直接是否产生耦合，完成一个需求后是否带来了新的问题是否能多个备选方案来完成需求需求采集回到我们平台设计的案例上，经过用户访谈粗略的采集的需求：?单项业务壁垒是个困局，本质上是功能缺陷，打通数据壁垒?业务各个阶段的数据管理，要对数据底层进行管理?需要对由相同特性的报表实现快捷的生成需求背后：?可以一次性看更多的数据?可以方便的切换数据?可以更快的看到数据so，这个真的是客户想要的吗？整体上，用户想看什么数据？同时我也在思考下面的问题：深入分析用户需求搞清楚我们的客户是谁？定义好问题，搞清楚问题的本质，分析问题矛盾之处，我们要解决什么问题？我们要在多大范围内去解决问题，要解决跨度多长时间可预计的问题？我们的边界在哪里？我们的使命是什么？有了使命后再谈我们自己，愿景是什么？6.3模型建立在系统设计这个阶段，我们已经介绍了如何运用工具，还有用户需求的管理，接下来就是要把需求“消化”成我们需要的架构。但是架构不是平白无故就产生的，前文我们用登陆火星的案例也大概描述了系统的建设过程，那么在推导出架构之前，把用户的不那么清晰的诉求转化成严谨的业务概念模型就很有必要了。模型基础首先我们要搞清楚模型相关的概念：模型：是指用一个较为简单的东西来代表另一个东西。科学模型：是科学研究中对一类研究方法的通称，使用数学公式、电脑模拟或简单的图示来表示一个简化的自然界，透过分析这个模型，以期能够进一步了解科学，包括说明、验证假说、或分析资料。概念模型：是用一组概念来描述一个系统，或用任何代替的形式来描述一个概念，以期能进一步了解或说明事物的运作原理。具体的形式可能包括思想实验、数学模型、电脑模拟、示意图、比例模型等业务建模：是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统建模目标也即是说业务建模是一种建模方法的集合，目的是对业务进行建模。这方面的工作包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。针对复杂难懂的系统，我们构造出一个比较简单的模型，来代表复杂的业务，这个是一种有效的办法，这也是我们需要建模的原因，随着计算机的飞速发展，或许以后计算机可以帮人类承当一部分的设计工作，而计算机是不怕复杂业务的，也许那个时候就不再需要这种特地适应人类思考的模型了。建立模型不是最终目的，而是把复杂的业务诉求构建成简单的业务概念，在软件开发团队沟通过程中能形成共识，消除歧义，而且信息传递不失真，为输出架构奠定基础。模型分类在业务不同的阶段，通常会使用不用的模型来表达，一般情况下我们把模型分为：业务模型概念模型系统模型分析模型设计模型物理模型建模方法建模有很多种方法，对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。建模是一种对现实事件的抽象，不同的心智会产生不同的模型，比如宗教，不同宗教就是对人生观世界观产生不同的模型，我们先介绍常用的建模方法：领域驱动（DDD）用例驱动（UDD）四色建模CRC建模CQRS建模下面我们以用例驱动和领域驱动为案例来介绍这两种思维方式的建模过程。用例驱动用例驱动是一种由外而内，先招式后内功的思想。我们先从涉众对系统的期望开始，定义出系统如何满足他们的愿望。这一过程是感性的、外在的、符合当前需求的。用例驱动的结果是我们的软件是以实现一个个场景为目的的，认为当一个系统的行为满足了所有涉众的期望之后，即满足了涉众使用系统的场景之后，该系统就是一个成功的系统。建立用例用例定义：工具—过程—操作数（主谓宾）参与者：某些具有行为的事物，可以是人，计算机系统或组织场景：参与者和系统之间的一系列特定的活动和交互用例：一组相关的成功和失败的场景集合，用来描述参与者如何使用系统来实现目标用例规范用例其实就是对一件独立事情的描述，这非常符合我们人类语言的表达过程，我们日常沟通很大部分是陈述一个观点，那就是以主谓宾的方式来表达，同样的编写用例也可以遵循这个结构。建模过程用例模型用例：每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例模型：用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用用例有严格的规范，回顾上文系统分析里面，我们对系统功能分析给出一个公式：功能=主体+操作+操作对象那么用例也是需要这样的结构，比如“我爱你”是完整的用例，能完整的描述一件事情，而“爱你”则不能称为一个用例。所以用例模型建立阶段就要力求把用户诉求都完整的以用例表达出来。业务模型业务模型：业务模型采用业务用例来绘制，表达业务的观点。我们在数据平台对用例模型进行抽象。分析师为客户制作业务报表抽象起来就是分析师制作报表，这个是我们最朴素的模型，我们以这个最原始最核心的用例为立足点点开始发散。主语：分析师状语：客户谓语：制作定语：某一项业务宾语：报表经过我么对语言的分析，已经很清晰的呈现出我们的业务模型，就是分析师制作报表，加上状语和定语的修饰，我们知道是为客户这个主体创建的报表，而且是特定领域的报表，状语就是跟分析师强相关的。概念模型概念模型：概念模型是一种或多或少的形式化描述，描述的内容包括建立软件组件时，所用到的算法、架构、假设与底层约束。这通常是对实际的简化描述，包括一定程度的抽象，显式或隐式地按照头脑中的确切使用方式进行构建现在我们明确了业务模型后，接着就是细化用户，补充更多的细节：分析师为不同的客户制作不同业务的报表分析师为不同的客户制作几款业务的报表分析师为不同的客户制作一项业务不同区域的报表两个分析师为某个群体用户制作业务线的报表客户授权某个群体查看不同业务的报表结合我们对业务的了解，可以丰富领域的属性，还有一个隐性的“权限”名词，我们需要独立出来，因为权限不属于任何一个领域。通常我们需要角色概念来管理用户访问报表的权限管理员为不同的客户创建一项业务不同区域的角色管理员为不同的客户分配一项业务不同区域的角色小二为不同报表创建不同权限系统模型系统模型：系统模型是一个系统某一方面本质属性的描述，它以某种确定的形式（如文字、符号、图表、实物、数学公式等）提供关于该系统的知识。丰富业务场景后，整体的用例如下图：分析师为不同的客户制作不同业务的报表工程师为制作个性报表小二给不同业务创建报表模板来生成报表小二创建权限来匹配报表客户创建角色客户分配角色客户筛选人群进行营销活动前置条件：业务告警？领域驱动用例驱动的一种从局部到全体的思维方式，刚刚接触某一行业的人员从零开始来了解业务，复杂业务很难一开始就拥有上帝视角来分析业务。而领域驱动则是一开始就站在上帝视角来着手业务，领域驱动要求化整为零，它是一种由内而外，先内功后招式的思想。它要求团队里有资深的业务领域专家，该专家对业务领域极其了解，不但要了解其然，还要理解其所以然，或者是能够跟领域专业人员学习到足够的领域知识。在此条件下，团队将从业务领域里找出反映业务本质的那些事物、规则和结构，把它抽象化，描述业务运行的基本原理和业务交互的机制，识别出用户的首要利益。领域驱动需要领域专家深度参与，访谈专家，才肯跟得出领域模型，单靠技术人员本身很难得出完成得领域模型。语言就是承载思想或者想法的模型，不同的语言建模出不同的思想，中西语言差异早就思维差异，所以需要领域模型需要从语言谈起，语言描述的事物，由于领域模型本质上传递的是概念，是知识性的信息，语言正是让知识传递成为可能。对于软件开发的场景来说，把这些知识显式化，能快速对齐不同角色、不同参与方之间的概念，加速沟通，避免误解。领域模型我们先得搞清楚领域模型的概念，然后才有领域驱动。领域模型是采用业务对象建立起来的一种模型，我们把领域模型当中使用到的业务对象称为领域类。回顾我们学了很多年的面向对象变成设计，而实际上真正使用面向对象开发的思维却是比较稀少的，比如传统MVC架构下的web开发，基本是失血模型的对象，让我们很少真正使用面向对象来实现我们的业务。而真是由于缺少面向对象的业务实现的必要训练，让很人使用领域驱动时觉得困难重重，这就需要我们对领域模型有一些基本的认识，然后在训练中来深化对领域模型，面向对象的认识。领域模型的核心思想是对象，而领域驱动的核心是分层，需要对实现架构进行分层，不同的团队，不同业务可能会有相应不同的分层，但是整体上分层的思想就是解耦，把复杂的事情分解开来简单化处理。传统架构挂着面向对象的名号，实际上干的全是面向过程的勾当，用户界面，数据库操作以及其他辅助性代码进程被写到业务对象里面，原因就是能让业务快速的跑起来，而领域驱动则打破了这个传统，给出了通用的架构解决方案，包含4个概念层：接口层负责向用户展现信息以及解释用户命令应用层很薄的一层，用来协调应用的活动。它不包含业务逻辑。它也不保留业务对象的状态，但它保留有应用任务的进度状态领域层本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态。对业务对象和它们状态的持久化被委托给了基础设施层设施层本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支持库等作用将应用按层分离并且建立好约束的交互规则是很有必要的，代码如果没有被放在正确的位置上，则很快会发生混乱。领域层最核心的职责只应该关心领域方面的业务问题。基础设施则只需关心底层的数据交互和外界的数据通讯交换，而无需