分析设计.ppt

领域驱动建模(Evans DDD),彭晨阳,Evans DDD,2004年Eric Evans 发表Domain-Driven Design Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD 领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道,Evans DDD,领域模型重要性,没有领域模型，只是靠代码编写完成一个又一个功能，复杂的领域需求会使得他们无法交流讨论，使工作陷入泥沼。 有少许领域模型，但是没有维护好模型与代码直接的联系，两者产生差异，无法实现。,DDD优点,分析设计发展的三个阶段,第一阶段：围绕数据库的驱动设计，新项目总是从设计数据库及其字段开始。 第二层次：面向对象的分析设计方法诞生后，有了专门的分析和设计阶段之分，分析阶段和设计阶段是断裂的。 第三阶段：融合了分析阶段和设计阶段的领域驱动设计（Evans: DDD）。,第一阶段：传统的数据库方式,过去软件系统分析设计总是从数据库开始，这种围绕数据库分析设计的缺点非常明显： 1.分析方面：不能迅速有效全面分析需求。 2. 设计方面：导致过程化设计编程，丧失了面向对象设计的优点。 2. 运行方面：导致软件运行时负载集中在数据库端，系统性能难于扩展，闲置了中间件J2EE服务器处理性能。 对象和关系数据库存在阻抗，本身是矛盾竞争的。,第二阶段：分析和设计分裂,第二阶段比第一阶段进步很多，开始采取面向对象的方法来分析设计需求。 分析人员的职责：是负责从需求领域中收集基本概念。面向需求。 设计人员的职责：必须指明一组能北项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题 两个阶段目标不一致，导致分裂，项目失败。,分析模型,分析模型会有知识不断消化的过程，但在编码时这些知识会被遗弃。 开发人员被迫为设计进行新的抽象，那么分析人员嵌入模型中知识不能保留和重新发现。 分析模型很多重要发现更改往往出现在设计实现过程，预先的模型可能深入研究无关主题，忽视重要主题。,蜘蛛网式模型类图,问题,一个印在大纸张上的完整类图，整面墙都被它覆盖，花几个月分析开发的领域模型，模型大多数对象都与其中三四个对象有错综复杂的关系，且关系网几乎没有自然边界。分析人员是忠于领域需求本质。 问题：开发人员开始实现应用程序时，彼此纠缠的关系根本无法转换成可存储 可检索的实现。 是不是基于概念的模型类图不能成为程序设计的基础？,DDD领域模型特点,统一领域模型：同时满足分析原型和软件设计 ，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。 统一语言：一个无处不在(ubiquitous )的语言，项目中所有人统一交流的语言。减少沟通疑惑，减少传达走样。使得软件更加适合需求。 建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此，建模专家必须懂设计。,Cargo需求,跟踪顾客货物的关键装卸事件 对货物进行实现预约 当货物在运输抵达某点时，自动向顾客发送信息。 这是一个跟踪物体流动的软件系统，关注重点是跟踪事件；顾客预约；货物装卸过程中。,传统分析思路,传统设计实现,CustomerService: 提供有关客户关系操作。 create(Customer customer); . CargoService：提供货物有关操作。 create(Cargo cargo); getLocation(Cargo cargo);,是面向对象吗？,缺陷：,Cargo和CargoService 首身分离。 货物的装卸系列事件或行为应该被封装在货物这个边界内。 维持逻辑上的一致性。因为不同装卸事件会引发货物本身状态变化。,逻辑的一致性Logical Consistency,无逻辑一致封装的失血模型,public class A private int lower, upper; /两个状态值 public int getLower() return lower; public int getUpper() return upper; .setter方法. A模型要求逻辑上一致性是：状态值lower必须小于状态值upper，lowerupper。,失血模型的调用,class ClientService public void setAUpper(int value) if (value a.getLower() a.setUpper(value); public void setALower(int value) if (value a.getUpper() a.setLower(value); 逻辑一致性判断被放在了客户端或service中，而不是在模型A内部，这样问题造成A的状态结果混乱，会出现A.upperA.lower情况。,破坏A的逻辑一致性,假设A的lower和upper的初始值是(0, 5)； 同时下面两个请求事件发生： 一个客户端请求线程A: setLower(4) 一个客户端请求线程B: setUpper(3) A的状态是：lower和upper是 (4, 3) 破坏A模型逻辑一致性要求lowerupper。,将操作状态的行为封装入A边界内,public class A private volatile int lower, upper; /两个状态值 public int getLower() return lower; public int getUpper() return upper; public void setAUpper(int value) if (value a.getLower() a.setUpper(value); public void setALower(int value) if (value a.getUpper() a.setLower(value); 更严格的悲观锁synchronization，值对象比synchronization更优雅。,内聚与边界,无名天地之始，有名万物之母。故常无欲以观其妙； 常有欲以观其徼（jiào）。 事物因内聚而有边界，故而有名。,领域模型的核心目标,模型 = “是什么（名）” 。 模型 != “怎么做”。 程序 = 算法 + 数据结构 ？ 算法 = “怎么做”，算法也是被设计的对象。 数据结构 = “僵尸” 模型在哪里呢？,算法的内聚特性,算法或计算非常复杂，导致设计受到了冲击变得混乱。 设计中产生了一大堆用来实现算法 解决问题的方法，而描述这个问题的方法变得模糊不清。怎么做的方法在模型中泛滥成灾，表明模型存在某种问题。 计算机制本身存在内聚性，我们计算方法不可能把所有功能都包含进来，我们需要的也不是一种万能计算机制。 使用策略模式等框架把这些内聚计算分离出来，用一个明确接口来说明这个框架的功能，将怎么做复杂细节交给框架去完成。,领域模型切割,1.将复杂大的领域分割成子领域。 2.抓住子领域的核心，建立核心模型，用聚合划定边界。 3.对核心模型实现灵活性细节设计,聚合Aggregates,聚合代表业务核心模型。 聚合= 聚合根 + 聚合边界。 组 = 组长 + 小组边界 聚合因内聚而存在 聚合内部维持逻辑一致性 DDD核心是找出聚合。,聚合,代表一个类是另一个类的一部份这种关系。 全体-部分 箭头由表示whole的类指向表示part的类 模型之间关联尽可能使用聚合表达,代表内聚组成的关联关系,关联要反映最本质的关系。如学生 课程 车和马达。关联不是手头任务本质或不能反映模型对象基本含义，完全取消它。 现实世界中存在大量双向多对多关联关系，双向关联和实现和维护带来很大困难，双向关联极少将联系本质体现出来，少用双向关联。 尽可能约束关联，通过指定导航方向，减少不必要关联。 模型中关联越少、越简单越好。,高内聚 低关联,高内聚 低关联是设计基本原则。是重构的准则。 找出关联是细分模型的一种方式，从而更恰当地定义模型边界。 关联不是手头任务本质或不能反映模型对象基本含义，完全取消它。 少用双向关联，除非技术性能要求。 模型中关联越少、越简单越好。 完全摆脱数据库影子，SQL语句作为规则封装在模型中。,找出聚合,论坛关联关系的提纯与精炼,四色原型：辅助找出聚合,四色使用颜色这种直观对事物进行分类。 类似于名词和动词等语义分类。 四色能够将动静分离，考虑人机交互。 四色的特点是能够比较全面宏观认识需求。,原型建模分析步骤,四色图,属于分析建模，属于Archetypes原型。 在成千上百的业务和工程系统由四种原型组成： 1. 橙色的Moment-Interval 简称MI 2. 黄色的角色 简称Role 3. 蓝色的description 4. 绿色的party, place, or thing .,四色原型DNC,大多数业务系统是由多个四色图反复拼装而成，我们称为这种现象是Domain-Neutral Component模式 用这种基于语义的类图模板进行任何系统的域建模 。 异常的简单好用 ，指导帮助更加完整地对复杂系统建模 。,四色原型详细,MI：时刻时段，表示活动 事件，粉红色核心 MI实现类有些类似: /* MI */ public class Sale public BigDecimal calcTotal() private int number; private Date date; ,角色 描述 PPT,角色：参与方 人或组织机构 描述description：分类目录，一组反复使用的值，值对象。比如：你的车（序列号 购买日期 颜色）属于车辆描述分类：制造商 型号 制造日期和可选颜色，后者是描述。 PPT： party 指人或组织 place可能是零售处或批发处, thing 在不同业务活动不同角色。,四色原型图,蓝色包含类型 描述 个数和缺省值。 绿色PPT则表达蓝色在当前这个系统中扮演的一个特定实例对象，包含它的序列号 名称 地址和顾客。 黄色：被分配的编号和状态 粉红色：编号 日期段 总价和状态,蓝 绿 黄 红序列,上图描述意思是：很多数量的具有类型 描述(蓝色)特征的东西被某个角色(黄色)分配，分配活动有一个日期以及所有东西总价计算(粉红)，具体分配活动结果贴在了这个东西(绿色PPT)上，包括顾客名称和地址等。 PPT更象一个参与者参与系统活动的结果、关联结果体。 什么东西被什么人做了什么事情，产生了一个什么结果。 什么人对什么东西做了什么事情，产生了什么结果。,蓝 绿 黄 红序列,1.蓝：它是不是属于一种种类性质的描述，或者代表一组呢可以反复使用的概念。 2.绿：如果需要单独着重跟踪参与方或某个地方或某个物品，不只是单独记录数量这样简单事情，需要特别关注。 3.黄：是否有和角色相关的职责。 4.红：需要记住相应的时刻和时段，它是不是依赖时间上瞬间或一段短时间存在的。,Cash sales用例提炼,Cash sales四色原型,模板:什么人对什么东西做了什么事情， 产生了什么结果。 收银员卖商品(包括:扫描条形码 计算总价 收钱支付)。 本案中，我们无需跟踪结果，所以没有PPT，侧重是卖商品这个过程涉及的一系列操作和状态改变。,四色与聚合,四色与聚合 上下文,有界上下文场景,在场景中，可以对聚合的状态进行断言，验证聚合设计的正确性。 场景能对模型进行验证，但是因为但细节无法左右模型设计。,聚合根Aggregate,一个聚合是一簇相关联的对象，出于数据变化的目的，将这些对象视为一个单元。 每个聚合都有一个根和一个边界。 边界定义了聚合中应该包含什么。 根是包含在聚合中的单个特定实体。 根是聚合中唯一允许被外部引用的元素，在聚合边界内，对象之间可以相互引用。 实际就是整体和部分的关系。,轿车根,Cargo货运路线案例,聚合内之间不可随意关联,聚合体之间 只引用对方的聚合根,聚合体内部模型元素,实体（Entity） A thread of continuity and identity. 在时间上一系列连续性（continuity）和标识（identity ID）来定义。 值对象（Value Object）： 如果一个对象代表了领域的某种描述性特征，且没有概念性的标识。Description原型。,实体,实体就是在客观世界中有实体内容的物体对象。经过时间延续一直保持其特点不变。 软件实际是客观世界的拷贝或镜子，实体就是镜子中那个实物。 必须拥有自己的唯一ID，主键，如果没有一个ID标识，为每个实例加上一个具有唯一性ID，可能是内部使用。 由于对象主观认定性，在特殊情况下，我们可能会主观划分一些实体。,聚合体内部切分,值对象,许多对象没有标识，只是事物的某些性质描述。 四色原型中的蓝色des直接对应值对象。 将所有对象都加上标识，会影响系统的性能，增加复杂性，使所有对象看上去都是一个模式，混乱。 只关心what，不关心who 或 which，只关心对象是什么？如果有多个这样对象排列在一起，我们不用去分辨它们。 只关心what：有两只相同颜色和粗细的笔，随便拿一个都可以画画。,实体切分实体和值对象,值对象设计,由于不关心软件运行时使用的是值对象的哪个实例，没有了分辨拘束，可提升性能和优化。 值对象复制性：两个人具有相同名字，表示名字的值对象可以互换复制，不会使他们成为一个人。 值对象共享性：两个Person对象不需要自己各自的Name值对象，可以共用一个Name值对象。 值对象不变性：值对象属于实体，当实体把它的值对象传递给其他对象时，如果其他对象对这个传过来的值对象修改不当，就会破坏其所有者的不变性约束，从而破坏它的所有者实体对象。,值对象共享,值对象非常巨大，每个电源插座都是一个值对象，一个房子有上百个插座对象，由于值对象可以互换 共享，只使用一个插座实例就可以。 Flyweight模式：避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类)。 不适用于实体。,值对象复制,Prototype模式允许一个对象再创建另外一个可定制的对象，根本无需知道任何如何创建的细节。 Java的clone也是一种复制。 复制产生大量对象会阻塞系统，但适合在分布式系统中，相反，使用共享，会降低性能； 高并发系统中，复制减少锁处理，共享需要精妙的锁处理技巧。,状态用值对象表达,状态的改变是原子性的。 状态具有不可变性。一旦构成不再改变 class MyState private final int lower; private final int upper; public MyState(int lower, int upper) this.lower = lower this.upper = upper; ,采购订单,订单不变量约束,所以采购单项的金额之和不得超过采购单的最高限额。 不变量保证：当加入新子项时，PO对总金额检查，如果不对，把自己标记非法，不好。 变更管理：删除PO时，子项同时删除，但是它们关联关系何时终止，模型没有指示。不同时间修改商品价格会造成哪些影响无法评估。 并发共享：如何解决多个用户同时修改一个PO?,并发锁粒度,如果多个用户同时修改一个PO，我们必须对这个PO实例锁定，以让某个时刻只能一个用户修改。 通过数据库锁机制或者使用线程锁机制实现，关键是锁PO整个实例带来问题，这种锁排他性的，就无法允许其他用户也许对PO其他部分进行访问，性能差。 更改模型，根据修改频繁程度单独列出一个对象，比如Price经常修改，就成为Price对象，锁定Price这个小对象，无需锁定整个PO。,状态作为独立对象,Jdon分析法,与四色在语义上的一致,蜘蛛网式模型类图,购书需求,分析一个系统要从Jdon分析法的横向和纵向方向： 首先纵向，用DDD找出聚合根实体，代表这个系统的结构本质，很显然这里是BOOK。 再从横向：用户发出操作命令产生事件，在这个系统中，用户发出挑选或购买书籍BOOK的命令，也就是购书活动，改变了聚合根BOOK的状态。 什么状态呢？ 1. 挑选命令致使BOOK放入购物车， 2.购买书籍命令致使BOOK加入了订单。,选书场景,买书场景,Cargo用例：什么人做什么事,Cargo四色图,Jdon分析法,聚合粗图,深入细节重构突破,隐式和显式,在需求中找到隐式概念，把它转为显式就是一种突破。 不断细化，当开发人员识别出某个概念，就会对设计和代码进行修改，加入一个或多个对象和关系，将这个概念显式表达出来。 检查不协调的地方。 研究矛盾之处。,显式约束,找出规格,规格代表一种事物的特征，事物区别于其他事物的特征约束。 很多业务规则和算法，包括复杂查询都可以Specification模式来实现。 大量使用Specification模式，将Specification模式整入领域模型，变成充血真正对象模型。,细化直至模型有一定的灵活性,灵活性就是抓住本质，考虑长远拓展。 领域中一定某个地方存在一种旋律和共鸣，存在内在一致性，模型要与领域某个部分发生共振。灵活设计可以使模型更加趋近这个旋律，随着项目开发的进行，感到速度越来越快，而不是越来越慢 。 没有通用菜谱式的规则，粒度大小是否适当？是否符合具体情况。 过度复杂过度工程(overengineering)打着灵活性旗号，多余的抽象和间接层次弄巧成拙 反复重构带来柔性。,Specification规格模式,业务规则不适合放入实体和值对象，规则的变化和组合会很多，包括各种算法或者条件判断，这些会掩盖领域对象的基本含义，这些就放入专门对象Specification中。 Specification表示业务规则，有指定要求的意思。 Specification类似围绕实体的值对象。,Specification种类,验证：验证一个对象，看它是否满足某些业务要求，或者是否已经准备就绪，与状态有关。 筛选过滤：从一个集合中筛选出符合指定要求的对象。类似SQL的Where语句 按需创建：创建一个对象时指定该对象必须满足某种要求。下订单要求厂家按照指定规格生产产品。,运输规格Specification,运输路线或目的地属于一种对货运运输的规划。 运输规格：目的地和抵达时间。 在运输目的地和Cargo之间引入第三者规格类，可以实现灵活的运输路线策略替换。 运输具体行为可能复杂多样，单独抽象作为一个类，能够应付复杂变化的运输方式。 将“做什么”和“怎么做”分离。,更改完善后四色图,增加细节,前面类图是一个细化的静态类图。主要增加了下面几个类： Delivery History 这是一个货物的运输历史记录实体，用来记录Cargo的装卸事件。 Carrier Movement特定运输工具卡车或货轮从一个地点到另外一个地点，这是确定好的，Cargo是否能够搭上Carrier ，需要预约。这个对象属于预约应用模块。,区分实体和值对象,该需求是为货物的预约运输以及装卸事件，显然Cargo是一个聚合根。 而Delivery Specification是从Cargo中分离出来，无疑属于聚合边界内 Delivery Specification 是实体还是值对象？ Delivery Specification实际是一个运输规则，如果两个货物的目的地相同，它们可以共享同一个Delivery Specification 。因此Delivery Specification是值对象。,聚合,Repository定义,数据库只是对象的永久保存方式，就象我们打字时经常需要存盘一样，我们不能因为要“存盘”而去关心“存盘文件格式(数据表结构)”。 我们应该更聚焦在模型这个对象，把所有对象的保存(冬眠)和调用(激活)交由Respository完成。 对象保存到数据库交由专门的Repository仓储来完成，由Repository负责如何将对象分解成数据库能够保存的格式。,查询仓储Specification,查询存在大量项目，但必须是围绕实体聚合根对象的查询，可以使用专门框架。 引入Specification制定，用来让客户端将它希望获得的查询结果描述出来，也就是制定出来。 输入参数使用Criteria来封装各种查询输入参数，提供Criteria的查询框架比较复杂，如Hibernate的Criteria。 如果聚合中有大数据，可通过懒加载lazy延迟加载，只返回一个代理，使用时，再进行加载。,Repository,需求改变：货物目的地改变,有顾客打电话说：希望将原来送货到Hackensack，现在必须把它送到Hoboken，系统必须支持这种改变。 由于Delivery Specification是一个值对象，可以扔掉再新建一个，再调用Cargo的settet方法把原来Delivery Specification替换成新的。,重复业务,用户告诉我们：同一个顾客多次重复预订往往类似的，他们希望用旧的Cargo作为原型创建新的Cargo。 使用原型模式Prototype来复制Cargo。 Cargo是一个聚合的根，因此有其他子对象，复制时必须小心。边界内每个子对象都要逐个处理。 值对象Delivery Specification直接创建新的。 复制时原则是不要对聚合边界意外的任何对象产生影响。,聚合的生命周期,在生命周期中维护对象的完整性。避免模型由于管理生命周期的复杂性而陷入困境。 三个模式来处理： 1. 聚合（Aggregate）：定义清晰的所有权和边界使模型更加紧凑，避免出现盘根错节的对象关系网。聚合圈出一个范围，在这个范围中，对象无论在哪个生命周期，保持不变性。 2. 工厂（Factory） 3. 仓储（Respository） 生命周期之始，使用工厂和组合提供了访问和控制模型对象的方法,生命周期边界和管理,聚合圈出一个范围如前图中红线，在这个范围中，对象无论在哪个生命周期，保持不变性。也就是子对象和父对象的生命周期是一致不变的。 建立聚合的模型，并且把工厂和组合加入设计中来，可以使我们系统地对模型对象生命周期进行管理。 生命周期之始，使用工厂和Repository提供了访问和控制模型对象的方法。,工厂,生命周期管理具有复杂的职责，如果让一个复杂对象来负责自身的创建工作，会由于职责过载产生问题，人不能拎着自己头发拔高，孙猴子也是从石头缝里出来的，不是从自己身体钻出来的。 复杂对象的创建和组装应该由单独工厂实现，也就是工厂模式。将对象创建和使用分离。 工厂属于领域层，工厂把聚合作为一个整体创建出来，创建方法必须是原子的，保证其不变量得到满足。,专门工厂创建聚合,如果聚合根需要一个工厂创建，又不适合充当工厂，也就是没有一个自然地方容纳工厂，那么就创建一个专门的工厂对象或服务。,Cargo工厂,无论为Cargo创建一个强大工厂还是用复制原型来作为工厂，我们都需要一个基本构造方法。构造方法产生的对象能够满足自身不变性。,HandlingEvent,当货物发生装卸事件时，用户会通过界面或系统Incident Logging Application输入一个Handling Event。 Cargo和装卸完成时间以及事件类型可以组成一个Handling Event对象,HandlingEvent工厂,创建一个新装卸事件，是使用Carrier Movement进行运输的装卸事件，将货物装到Carrier ，下一步由Carrier 运输。 装卸事件类型有：装货 卸货 加封条 存放。 下面是庄家一个装货事件的工厂代码,避免同时修改引起的竞争,每当增加HandlingEvent时，需要把这个新事件加入Delivery History， Delivery History是保存以往所有装卸事件。这样我们才能从Delivery History中跟踪装卸事件。 如果某个其他用户正在修改Cargo，当前HandlingEvent正在将自身通过Cargo加入Delivery History的HandlingEvent集合(如addHistory)。这样就发生两个同时并发修改，其中一个事务将失败或被推迟。 增加HandlingEvent进入Delivery History是一个很重要的事务过程，必须确保没有干扰下无竞争环境中安全可靠执行。输入HandlingEvent必须是简单快捷。 将Delivery History的HandlingEvent集合用查询替代,查询还是关联,获得一个对象有两种方式：通过聚合根；通过直接查询。 原来我们将HandlingEvent加入DeliveryHistory的集合中，两者是一个多对一关联聚合。 DeliveryHistory和Cargo是一对一关联，记录Cargo的运输历史。 HandlingEvent和Cargo又是一个关联，形成一个封闭循环。 将HandlingEvent和DeliveryHistory的多对一聚合关联去除，用查询来替代。,查询Repository替代关联,HandlingEvent仓储,HandlingEvent Repository提供根据一个给定的ID来查询Cargo来功能。如findCargoByTimeType or findCargoByTracingID来查询。获得HandlingEvent集合。 然后用户输入新的HandlingEvent，只要直接加入这个查询出来的集合就可以。加入HandlingEvent就不再受其他事务干扰。 这个集合可以保存在内存中。,模型完整性,实现大型系统领域模型的完全同意是不可行的或者代价太高。 需要统一的部分保持一致性，而不需要统一的部分不会引起误解甚至被破坏。 需要一种在不同模型之间标记界限和关系的方法。 Bounded Context:确定每个模型的适用范围。 CONTEXT MAP 描述项目场景全局和它们之间的关系。 区分场景context中还是场景本身！然后依靠项目管理方法持续集成保证模型的统一。,Bounded Context场景边界,当大型项目采取多模型开发，当组合到一起后，发现混乱，搞不清楚一个模型的场景应用是什么。 明确定语模型应用时的场景，包括头脑风暴讨论主题场景，在程序各个部分根据使用率 物理位置数据库还是代码库，设置界限，在这些界限中保持模型的一致性。,持续集成,持续集成意味着合并场景内所有工作，经常保持它们一致性。每天集成。 分模型概念集成和实现集成。 分步骤 可重用的合并和创建 自动化测试集 设定一些规则，对没有集成的变化设立稍高的生命期上限。,CONTEXT MAP场景映射,运输案例,需求：预订时候能够自动计算出货船的航线。,两个边界上下文,转换映射,Shared Kernel,指定模型中两个团队同意共享的子集，在没有与对方商量前不得自行改变。 共享内核通常是核心领域，可以是模型任何部分，减少重复开发，降低持续集成频率。,Anticorruption Layer防腐层,如果新系统必须和其他系统依靠大型接口连接，那么如何处理这些接口？ 根据两个领域模型创建一个隔离层，该层通过现有接口与另外一个系统会话，而无需修改那个系统。 Façade模式 adapter模式适合。包括JMS SOA都是合适的防腐层。,防腐层,Distillation提炼,虽然分层架构可以将业务领域概念和计算机系统运行所需要的技术逻辑分离开来，但在一个庞大业务系统中，这点是不够的。 模型提炼优点： 1. 提炼出特别有价值部分，就是核心领域。 2. 帮助团队把握整体设计 3. 核心模型抑郁控制 4. 指导重构,货运案例,核心领域,非核心,大型系统架构,以一种很大力度来讨论和理解系统，从高层次概念为系统设计一个模式，有助于分工合作。 按照职责进行分层是一种好的模式。,货运案例,货运顺序图,分层,发现其中一些自然层次，讨论运输计划时可以不考虑运输工具上是否装载货物。但是在对货物进行跟踪时，必须考虑运输工具，两个是分离的。 将系统分为：操作层Operation和支持资源层Capability Cargo是公司每天关心的，是公司计划的核心，Route Spec是Cargo聚合部分，整个聚合边界都是属于操作层。 资源层是公司为完成计划作业而需要的资源，船队transit leg是一个例子。客户customer也是一种资源。,分层,