andy的博客

只供参考，喜欢请支持正版图书11.5.2 现在行动：建立分析模型11.6 组件模型11.6.2 现在行动：建立组件模型组件是一种特殊的包，它用来组织已有的类11.7 部署模型部署模型又称为实施模型。它主要的作用就是定义构成应用程序的各个部分在物理结构上的安装和部署位置11.7.2 现在行动：建立部署模型只供参考，喜欢请支持正版图书...

只供参考，喜欢请支持正版图书一个用例可能有多个用例实现，每个用例实现都是设想的一种实现方式。虽然实现方式和过程不同，但目的是相同的，同样要达到用例所规定的系统目标。为了表示出用例实现与它所实现的用例之间的关系，我们可以用图11.13来表示。这幅图表明了实现到需求之间的追溯关系11.3.2 现在行动：实现用例在5.6.3分析模型的意义一节中作者介绍过，分析模型是采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）和实体（业务数据），用这三个元素建立实现用例场景的对

只供参考，喜欢请支持正版图书11.1 确定系统用例具体说来，这些方法包括：■　映射映射是最简单最直接的方法，例如值机人员办理登机手续这个备选用例就可以不加修饰地直接被采纳为系统用例。■　抽象抽象也是比较常用的方法，当业务场景当中的备选用例不能够被直接映射时，我们可能需要进行一些抽象，找到该备选用例在计算机当中真正要做的事11.1.2 现在行动：确定系统用例图11.3　申请永久用电系统用例11.1.3 现在行动：描述系统用例■　用例场景示例我们先来看一个用例场景的例子，从图11.3所示

只供参考，喜欢请支持正版图书10.1 关键概念分析10.1.2 现在行动：建立概念模型10.1.2.1 获取概念用例10.1.2.2 分析概念用例10.1.2.3 建立概念模型在5.6.3分析模型的意义一节中作者介绍过，分析模型是采用MVC模式，将用例场景中描述的业务分解为边界（操作界面和展示界面）、控制（业务逻辑）和实体（业务数据），用这三个元素建立实现用例场景的对象模型。这就引出了软件架构的问题。的确是这样，每一个小步都可以理解为系统中的一个功能单元，或者说最小的操作集。系统只有将

只供参考，喜欢请支持正版图书9.5.2 现在行动：建立领域模型建立领域模型首先要确定领域，才能为之建模。何为领域？所谓领域就是我们分析问题时将整体分解以后的相对独立的部分在实际工作中，并不需要把问题完全分解成领域，也不需要为每个领域都建模，而只挑选那些对业务来说重要的、对过程来说核心的或者对系统来说复杂和困难的那些部分来建模。目的是在项目的初期就把对项目成败影响最为关键的那些部分搞清楚建立领域模型，我们需经过提出领域问题、分析领域问题、建立领域模型和检验领域模型这些步骤9.5.2.1 提出领域问

只供参考，喜欢请支持正版图书9.4.2 现在行动：建立业务模型在5.2业务用例模型一节中我们谈到过，一个完整的业务模型包括以下一些内容：■　业务用例视图■　业务用例场景■　业务用例规约■　业务规则■　业务对象模型■　业务用例实现视图■　业务用例实现场景■　包图9.4.2.1 业务用例场景示例从上面所获得的业务用例中选择了“bu_申请永久用电”这个业务用例来作为示例，看看各类业务用例场景是如何描述业务的■ 用活动图描述业务用例场景场景隐含着两个基本要求，一是必须忠实于真实业务，二

只供参考，喜欢请支持正版图书9.3.2 现在行动：获取业务用例获取业务用例有很多方法，可以从岗位手册、业务流程指南、职务说明等一些文件中获得，也可以从涉众分析中获得灵感。另外一种很重要的方法，就是业务主角访谈。在3.3.4用例的获得一节中我们谈到过，可以通过以下问题引导业务主角代表说出他们的业务需求：■　您对系统有什么期望？■　您打算在这个系统里做些什么事情？■　您做这件事的目的是什么？■　您做完这件事希望有一个什么样的结果？9.3.2.1 第一个例子在本案例中，业务员代表用电客户提出业务

只供参考，喜欢请支持正版图书9.1 定义边界边界定义的不同会带来不同的结果，因为视角会因边界而变动。那么有没有一种方法能帮助我们定义边界呢？有，通过前景文档当中的业务目标来定义边界会是一个好办法，我们就从这里开始着手。其实在边界这个概念之前，需求调研也是要先进行一些业务模块的划分的。传统意义上，这种业务划分通常是以客户的现有业务模块为基础，或者以客户的现有职能部门为基础来划分的。相信绝大部分读者仍然采用这种划分方式。不过这种划分方式却有一些隐患，它会带来系统边界的不清晰和依赖关系复杂的问题。相信很多

只供参考，喜欢请支持正版图书8.1 案例说明选取一个合适的案例是很困难的。作者曾经在博客中公开征集案例，其间也收到许多热心朋友推荐的案例，非常感谢朋友们的帮助，只可惜这些案例都不太合适。有的案例太小，比如一个论坛，无法串起更多的知识点；有的案例不够典型，比如库存管理，难以体现出UML的优势。作者在考虑的时候，更多的是在选择这样一个案例：它能够将尽量多的知识点串起来；它具备比较普遍的代表性；它很容易体现UML的优势；它的业务领域对大部分读者来说不会太陌生。衡量了很多，最终还是打算从服务行业选择一个案例

只供参考，喜欢请支持正版图书许多人将迭代计划与里程碑计划混淆。例如常有这样的迭代计划：迭代1→完成需求；迭代2→完成分析和设计……。很显然，上述所谓的迭代计划只不过是将项目分解为几个里程碑而已，而真正迭代的意思是，每一个迭代都经历一次完整的软件生命周期。什么意思？意思是，每一次迭代都有需求、分析、设计、实施。也就是说，每一次迭代的结果都能得到一个可运行的系统。6.4.3推荐的实施建模工作流程一节已经展示了一种基于迭代计划的实施过程。从中可以看出，迭代计划的目标是尽早地实现需求，得到一个可运行的系统。如

只供参考，喜欢请支持正版图书本章作者将列举出使用UML最多，也最为常用的几个工作流程。它们是：■　业务建模工作流程■　系统建模工作流程■　分析设计工作流程■　实施建模工作流程6.1 业务建模工作流程6.1.1 工作流程统一过程定义业务建模的工作流程如图6.1所示在此工作流程中，并非所有的路径和步骤都需要执行。在开始业务建模工作之前，应当评估并决定采用哪个（些）路径和哪些步骤。这项工作在“评估业务状态”这一活动步骤中完成■　如果你所面临的业务领域是客户已经很成熟的业务，客户并无改进其业务

只供参考，喜欢请支持正版图书5.1 用例模型概述用例模型的好坏将决定整个开发过程的好坏。用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用随着迭代的进行，用例不断地被识别，然后被实现，软件离现实世界的要求也就越来越近到这里为止，我们只是粗略窥视了用例模型的综合概念。我们谈到过用例有三个层次解释：业务用例、概念用例、系统用例，自然地，用例模型也就有业务用例模型

只供参考，喜欢请支持正版图书如果说UML是一门语言，上一章学习的元素是UML的基本词汇，那么视图就是语法，UML通过视图将基本元素组织在一起，形成有意义的句子。UML可视化的特性是由各种视图来展现的，每一种视图都从不同的角度对同一个软件产品的方方面面进行展示，说明将要开发的软件到底是什么样子。描述软件和描述现实世界一样，一方面我们需要描述系统的结构性特征，结构决定了这个系统能做什么；另一方面我们需要描述系统的运行时行为，这些行为特征决定了系统怎么做。两者结合起来才能把系统描述清楚。在UML里，结构性

3.8 设计类设计类是系统实施中一个或多个对象的抽象；设计类所对应的对象取决于实施语言。设计类用于设计模型中，它直接使用与编程语言相同的语言来描述。凡是使用过面向对象语言的朋友对类都不会陌生，到了这个阶段，设计类已经直接映射到实现代码了，因此设计类依赖于实施语言。另一方面，设计类来源于前期的系统分析，在统一过程中，类不是凭空想象出来的，它们可以一一映射到前期系统分析的成果物上。从这个观点出发，分析类的重要性就能够体现出来。分析类为设计类中所需要的界面、逻辑和数据提供了非常好的抽象基础，设计类可以非常容易

3.4 边界只供参考，喜欢请支持正版图书边界在UML图符里的定义只是一个简单的矩形框，矩形框的四个边决定了边界的内外。而在Rational的Rose这一最为著名的建模工具里，干脆连这个元素都省掉了。所以，相对于其他的UML元素，边界可能是最简单的，但也是最容易混淆的。面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道，而对象内部则是一个禁区。我们把边界放大了...

只供参考，喜欢请支持正版图书3.3 用例用例在UML建模中是最最重要的一个元素。之所以说它重要，是因为UML是面向对象的，除用例之外，所有其他元素都是“封装”的、“独立”的。回顾一下我们在1.1.3节面向对象方法中讲到的内容，这些元素在没有“外力”作用时是“鸡犬之声相闻，老死不相往来”的。而用例正是施加这一“外力”的元素，正是用例使得其他那些“孤独”的UML元素能够共同组成一篇有意义的文字。...

只供参考，喜欢请支持正版图书3.1 版型在UML里有一个概念叫版型（stereotype），有些书里也称为类型、构造型。这个概念是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。UML中几乎每一个元模型都有很多版型。例如用例有“业务用例”、“业务用例实现”等版型；类就更多了，我们熟知的“接口”、“边界类”、“实体类”、“控制类”等都...

只供参考，喜欢请支持正版图书2.1 建模建模的定义本身就和建模工作一样非常抽象和难以理解。为了理解，我们简单地说：建模包含两个问题，一个是怎么建，另一个是模是什么。让我们想象一下城市里遍布的摄像机，虽然它们拍摄的都是同一座城市，但不同的机位看到的情景是不同的，每个机位都反映出了城市的一个方面。如果我们要认识这个城市，就需要先明确我们想了解城市的什么，然后选择最有代表性的机位，从各个机位采集...

只供参考，喜欢请支持正版图书1.1 面向过程还是面向对象我对面向对象编程的目标从来就不是复用。相反，对我来说，对象提供了一种处理复杂性问题的方式。这个问题可以追溯到亚里士多德：您把这个世界视为过程还是对象？在面向对象兴起运动之前，编程以过程为中心，例如结构化设计方法。然而，系统已经到达了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统——我认为，这才是...

只供参考，喜欢请支持正版图书用户界面渲染领域对象渲染数据传输对象一种渲染多个聚合实例的方法便是使用数据传输对象（Data Tranfcr Object， DTO) [Fowler,PofEAA]。DTO将包含需要显示的所有属性值。应用服务通过资源 库（12)读取所需的聚合实例，然后使用一个DTO组装器（DTOAssemble) [Fowler, P of EAA]将需要显示的属性值映射...

只供参考，喜欢请支持正版图书集成基础知识有多种直接的方式可以完成限界上下文之间的集成。其中一种便是在一个限界上下文中暴露应用程序编程接口（API)，然后在另 一个限界上下文中通过远程过程调用（RPC)的方式访问该API。此时的API可以 通过SOAP协议暴露给其他限界上下文，也可以直接在HTTP中使用XML (这种方 式与REST不同）。事实上，我们有多种方式创建这样的远程API，SOAP...

面向集合资源库这些像集合一样的对象都是和持久化相关的。每一种聚合类型都将拥有一个 资源库。通常来说，聚合类型和资源库之间存在着一对一的关系。然而有时，当两 个或多个聚合位于同一个对象层级中时，它们可以共享同一个资源库。在本章中， 我们将分别对这两种情况进行讨论。严格来讲，只有聚合才拥有资源库。如果一个限界上下文（2)中没有使用聚 合，那么使用资源库也没有多大意义。如果你只是随机地、直接地获取和...

工厂

将实体⑶和值对象⑹在一致性边界之内组成聚合（Aggregate)乍看起 来是一件轻松的任务，但在ODD众多的战术性指导中，该模式却是最不容易理解。让我们首先来看看一些常见的问题。聚合只是将一些共享父类、密切关联的 对象聚集成一个对象树吗？如果是这样，对于存在于这个树中的对象有没有一个 实用的数目限制？既然一个聚合可以引用另一个聚合，我们是否可以深度地递归遍 历下去，并且在此过程中修改对象呢？聚合...

通过模块完成设计在DDD中，模型中的模块表示了一个命名的容器，用于存放领域中内聚在一起 的类。将类放在不同模块中的目的在于达到松耦合性。由于DDD中的模块并不是 一个通用的存储区域，因此对其进行适当的命名是重要的。事实上，模块名是通用 语言的重要组成部分。模块应该包含一组具有高内聚性的概念集合，这样做的好处是可以在不同的模块 之间实现松耦合。否则，我们应该修改模型以重新划分这些概念。……由于模...

何时、为什么使用领域事件领域专家所关心的发生在领域中的一些事件。将领域中所发生的活动建模成一系列的离散事件。每个事件都用领域对象来表领域事件是领域模型的组成部分,表示领域中所发生的事情。有时，从领域专家的话中，我们看不出领域事件的迹象，但是业务需求依然有可能需要领域事件。领域专家有可能意识不到这些需求，只有在跨团队讨论之后他们才能意识到这些。发生这样的事情往往是由于领域事件需要发布到外部系统...

什么是领域服务（首先，什么不是领域服务）请确定你是否需要一个领域服务建模领域服务独立接口有必要吗一个计算过程

值对象的特征不变性概念整体可替换性值对象相等性

唯一标识标识生成时间委派标识揭开实体及其本质特征的神秘面纱挖掘实体的关键行为角色和职责

分层依赖倒置原则六边形架构（端口与适配器)面向服务架构图4.5只是单个限界上下文的架构。

一个项目的上下文映射图可以用两种方式表示：1.画一个简单的框图来表示两个或多个限界上下文之间的映射关系；2.另一种更详细的方式是通过限界上下文集成的源代码实现来表示；上下文映射图为什么重要图3.1表示一个抽象的上下文映射图，然后不断的向里面添加细节内容；...

领域（Domain)即是一个组织所做的事情以及其中包含的一切。每个组织都有它自己的业务范围和做事方式。这个业务范围以及在其中所进行的活动便是领域。领域既可以表示整个业务系统，也可以表示其中的某个核心域或支撑子域。工作中的子域和限界上下文让我们先来看看一个非常简单的例子——一个零售商在线销售产品的例子。零售商的领域可以分为个主要的子域：产品目录（product catalog)、订单(ord...

**领域驱动设计（DDD)**作为一种软件开发方法，可以帮助我们设计高质量的软件模型。什么是领域模型？领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。贫血症和失忆症贫血领域对象它描述的是一个缺少内在行为的领域对象。...

开始使⽤ZooKeeper的API我们将会看到在应⽤中如何通过API来进⾏操作，我们还是从主-从模式例⼦开始进⾏编码3.2　建⽴ZooKeeper会话ZooKeeper的API围绕ZooKeeper的句柄（handle）⽽构建，每个API调⽤都需要传递这个句柄。这个句柄代表与ZooKeeper之间的⼀个会话，。在图3-1中，与ZooKeeper服务器已经建⽴的⼀个会话如果断开，这个会话就会...

2.1　ZooKeeper基础znode节点：ZooKeeper操作和维护⼀个⼩型的数据节点，采⽤类似于⽂件系统的层级树状结构进⾏管理。主节点的znode没有数据，表⽰当前还没有选举出主节点。·/workers节点作为⽗节点，其下每个znode⼦节点保存了系统中⼀个可用从节点信息。如图2-1所示，有⼀个从节点（foot.com：2181）；·/tasks节点作为⽗节点，其下每个znode...

ZooKeeper：它可以在分布式系统中协作多个任务。⼀个协作任务是指⼀个包含多个进程的任务。⽰例：主-从应⽤主节点进程：负责跟踪从节点状态和任务的有效性，并分配任务到从节点；备份主节点：主节点失效时，我们需要有⼀个备份主节点（backup master）。当主要主节点（primary master）崩溃时，备份主节点接管主要主节点的⾓⾊；CAP：表⽰⼀致性（Consistency）、可...