领域模型驱动设计(DDD)之模型提炼
; 当Java世界提供的可选择性框架平台越来越多时 我们可能被平台架构所深深困扰 而无暇顾及软件的真正核心 业务建模 其实 业务领域建模同样是一个比平台架构更复杂 更需要学习的新的领域
相反 在实践中 我们技术人员在经过冗长的平台架构学习和实践后 就匆忙开始项目开发 这时是什么指导他们进行软件业务实现呢？大部分可能是依赖数据库建模 甚至是复杂冗长的数据库存储过程设计 这些已经开始走向面向对象分析设计的反方向 走上了一条错误的软件开发方向 最终开发出缓慢的 经常当机的Java企业系统
如果你没有恰当的OO设计思想 Java就会用性能惩罚你 这可能是Java世界的一个潜规则
那么 一个正确的OOA/OOD/OOP步骤是什么呢？目前围绕模型驱动设计(MDD)的设计思想成为主流思想 MDA更是在MDD基础上提升和升华 下面让我们首先了解 如何使用领域驱动设计思想来分析设计一个软件系统
当我们不再对一个新系统进行数据库提炼时 取而代之的时面向对象的模型提炼 我们必须大刀阔斧地对业务领域进行细分 将一个复杂的业务领域划分为多个小的子领域 同时还必须分清重点和次要部分 抓住核心领域概念 实现重点突破
核心领域模型
精简模型 找出核心领域 将业务需求中最有价值的概念体现出来 让核心变精要 这实际就是一个使复杂问题变简单的过程 也是对我们软件设计人员真正能力的考验
核心领域模型不是轻易能够发现 特别是他处于一个纷乱复杂的众多领域模型结构中时 核心模型通常是我们某个子领域关注的重点 例如订单模型是订单管理领域的核心 消息模型是论坛或消息领域系统的核心
目前 分析领域有很多模式来帮助我们来提炼核心模型 例如四色原型 Martin Fowler 的分析模式等 例如MF的 分析模式 (Analysis Patterns)中的记帐模型就是不仅仅用来记录账目数值 而且可以记录和控制账目的每一次修改 而四色原型则是一种高于分析模式的一种原型基本模式 下面是本人根据四色原型提炼的核心领域模型概念
一般情况下 在企业应用中 核心模型总是在其周围围绕一些所谓的 卫星 这实际上也是来自四色原型的一个推论 核心模型和其 卫星 的类图如下
根据Eric Evans在其 领域驱动设计 一书中定义 领域模型划分为实体和值对象两种 实体模型是指业务领域中具有独立属性的对象 而值对象则可能是一种Description或状态或规则 只要有实体对象 就可能存在实体的状态 状态跟踪有时成为一个业务领域使用计算机软件的首要跟踪 但是 数据库不是对象状态的唯一表达方式 只是一种存储方式(见状态对象 数据库的替代者)
图中 实体核心对象大部分可能有一种类型 例如核心模型是产品 那么存在产品目录 核心模型是消息 就存在消息类型 核心模型是信息 总存在信息类别 我们总是使用分类方式来管理业务领域的信息 有时 类别甚至复杂到树形结构
核心实体模型有时会有一个 :N关联的子实体 一般可能表达实体的细节 例如 核心模型是订单 那么存在订单条目这样一个细节 一个订单中可能有多个订单条目 如果核心模型是信息 那么存在该信息的多个回复或评论 这样的关联一般存在多个业务领域中
模型界面实现
原来 我们以为分析设计阶段无需了解实现细节 分析人员只要闷头做分析UML图 而无需顾及如何具体实现 其实这是一个误区
Eric Evans在其 领域驱动设计 一书中认为 分析人员负责从领域中收集基本概念 设计则必须指明一组适应编程工具构造的组件 以及这些组件必须能够在目标环境中有效执行 模型驱动设计(Model Driven Design)抛弃了分裂分析模型与设计的做法 使用单一的模型来满足这两方面的要求 因此 对于核心模型必须掌握了解其实现细节
从另外一个方面来说 中国的客户总是从界面设计来表达他们的意图（如果中国客户能够使用Use Case等UML图来表达他们概念真是不可想象） 例如客户会说 我希望有一个界面让我将订单数据输入 然后能够查询符合查询条件的订单 因此 我们的核心模型至少能够顺利地映射到界面实现 相反 这个客户有这样订单界面要求 但是你没有提供一个与之适应的核心实体模型 界面实现将变得复杂 甚至走很多弯路 诞生不少DTO垃圾对象
以Jdonframework框架实现为例子 框架提供了围绕核心模型的新增删除修改查询(CRUD)功能以及批量功能的快速实现 尤其CRUD功能实现前提是必须提炼出核心模型 从而其界面设计流程就能通过配置立即实现 这样一步到位实现领域模型到界面的过渡 可以将我们设计核心模型和客户要求的界面需求能够做到完整的统一
开源Jdonframework下载包中message案例实际就是上述核心模型图的一种实现项目 更复杂的项目可以认为是核心模型的重叠和反复使用（从原理上讲 核心模型是四色原型的体现 而四色原型被认为是大部分企业系统的基本组成元素 见[book][UML][Peter Coad]Java Modeling in Color with UML）
核心模型的选择
实际项目中 会存在多个核心模型的重叠和覆盖使用 主要取决于你的领域关注重点
例如当客户和我们说要做一个旅游网站时 我们必须充分了解需求 它的软件系统重点是哪些功能 如果当他首先说 我需要一个酒店设备的查询系统 因为他的客户对酒店设备非常关注 那么我们可能认为酒店设备是这个领域模型的核心 酒店设备 如果他又进行描述 我需要一个界面 客户在输入酒店资料时 选择多个酒店设备 那么在这样一个关注领域 核心模型实际是酒店 而酒店设备可能成为酒店的一个特征实体属性 甚至是值对象了
以进销存系统为例子 在采购系统中 采购单是一个核心实体模型 而原材料是一种辅助实体模型 在库存系统中 入出库单是一个核心实体模型 原材料或成品代表的是一个库存物品概念模型 当需要库存报表查询输出 可以立即计算出来 或将结果缓存起来 缓存起来的结果其实是库存物品对象的状态 可以使用值对象来实现
核心模型的精练
lishixinzhi/Article/program/Java/gj/201311/27660
DDD领域驱动设计的项目实践
DDD的概念众所周知，各个文章中的基本概念也都大同小异。这里就不再累述了。DDD***的好处是使用 领域通用语言（UBIQUITOUS LANGUAGE） 将原先晦涩难懂的业务通过领域概念清晰的显性化表达出来。写这篇文章的目的在于学习怎么使用DDD来降低应用的复杂度，增加框架的可扩展性。本文主要阐述了我在项目中的思考过程和架构实现。
我们从以下一些方面进行些讨论以帮助我们完成DDD的具体实践。
分层***的意义是在架构的层面上来进行职责的拆分，分离关注点，每一层都确定独立的职责，分层内部保持高度内聚性，让每一层只解决该层关注的问题，从而将复杂的问题简化，它们 只对下层进行依赖 ，实现高内聚低耦合、职责分离的思想。
应用层代表。
那么应用层代表什么，就是代表系统；所以， 我们要明白人与系统的关系；人使用系统，系统提供外部功能，系统内部有领域模型；
这个问题，DDD通过DCI架构（Data、Context和Interactive三层架构），显式的用role对行为进行建模，同时让role在context中对应的领域对象进行绑定(cast)来解决。
待扩展.......
由于DDD分层架构这种向下依赖的模式使得整个框架对于Infrastructure层过度依赖，这不是我们所期望的，我们希望能在Application和Domain层更多的决定领域的功能和流程。所以根据DIP（依赖倒置）原则， 高层模块和低层模块都应该依赖于抽象，为了让模型的逻辑定义更为内聚，我们可以把抽象放在上层（Application、Domain），Infrastructure提供实现。
例如在现在的项目中，我们在Domain层中定义IRepository、ISender、IListener等行为接口，在frameworks and Drivers层(The Clean Architecture)实现接口，通过注入的方式提供给Domain层。这样能够使依赖的核心层更加内聚，同时对外层的扩展预留出了足够的空间。
（同样的操作我们还尝试的用在对领域层中，将领域对象抽象化，使领域服务依赖于领域对象的抽象，将真正的的领域对象交给更外层去实现，来满足我们架构对于相似业务的扩张能力。但这种做法是极具风险的，不同业务的差异化和领域对象抽象的能力都是极难把握的。总的来说，我们所期望的方向是：1.抽象能够涵盖所有业务。2.业务的差异化只在抽象的实现层被应用。只有满足以上2点，我们的想法才有可能被实现。）
聊完了高低层模块的依赖，我们再来聊下同层之间的依赖。
分层架构的一个重要原则是 每层只能与位于其下方的层发生耦合 ，有些书中还有严格分层架构和松散分层架构两种区分。两者的区别在于能否对非直接下层发生耦合。但有一点是相同的，同分层之间的耦合都是不被允许的。但问题是有些时候，实际情况使它并不是容易被实现的。
例如在我们的项目中，为了满足高吞吐的业务需求，我们选用了Actor模型和AKKA多线程框架来构建我们的架构。这种响应式的异步模式上层无法及时获得下层的反馈，这使上层对下层的协调、分配变得异常艰难。所以我们需要在不同的分层中都创建Actor进行交互，通过对sender的回件来进行解耦。（TODO:图）
Actor模型对于DDD的使用还是有很多帮助的，他们都有相同的对象理念，同时，这种响应式架构使领域事件到其他的边界上下文或微服务变得更容易。
经过一些分层、抽象，The Clean Architecture是我们项目期望的目标。
关于整洁架构...等有时间再写了...
The Clean Code Blog by Robert C. Martin (Uncle Bob)
领域建模是整个DDD中比较核心的步骤，大部分DDD的工程都是基于领域建模展开的。这里同样不再对实体，值对象等做过多的名词解释，只来记录一次领域建模的过程。
这是一个关于交易平台报价行情系统的部分需求：
1.交易员提交报价 2.交易员选择[群组]提交报价
3.交易核心处理报价 4.交易核心下发[报价报告] 5.交易核心下发[报价行情消息]
6.行情系统订阅交易核心相关消息
7.行情系统收到[全市场][报价报告]，开始计算报价行情：
a.根据[报价报告][计算]出[公有报价行情]。b.根据[公有报价行情][聚合]出[公有聚合报价行情]。c.根据[公有报价行情]为[机构]生成[私有报价行情]。d.根据[私有报价行情][聚合]出[私有聚合报价行情]。
8.行情系统收到[群组][报价报告]，开始计算报价行情：
a.根据[报价报告]为[群组]包含的[机构][计算]出[私有报价行情]。b.根据[私有报价行情][聚合]出[私有聚合报价行情]。
9.行情系统收到[公有报价行情消息]，开始计算报价行情：
a.将[公有报价行情消息][转化]成[公有报价行情]。b.根据[公有报价行情][聚合]出[公有聚合报价行情]。
10.行情系统收到[私有报价行情消息]，开始计算报价行情：
a.将[私有报价行情消息][转化]成[私有报价行情]。b.根据[私有报价行情][聚合]出[私有聚合报价行情]。
***步：分析需求，定义关键类，描述业务流程
1.从需求中抽象出我们所关心的类
Book:报价簿，报价行情形象话的表现
Page:报价簿中记录内容的抽象类
Institution:.........
2.建立类的大致内容、行为和关系
上图只是对类的简单定义，项目中最后落地一定不可能如此简单，需要进行反复的细化工作。
3.描述大致的业务活动图
第二步：划分主要构成
我们必须在这步中识别出模型中的实体、值对象，定义出核心域、子域并理清关系，划分应用层和服务层，确定限界上下文边界。
本需求寻找核心有两种方向，一种以 行情计算和聚合 为核心，机构、群组等作为独立子域；一种以 行情拥有对象（全市场、机构） 为核心，行情计算、聚合作为支撑子域；***种偏向横向分层，第二种偏向纵向分层。按实际情况，我们选择了第二种方式，围绕Owner(全市场和机构)展开它们的行情计算、价格预警、价格变化、单机构等等。同时，上面的类图、流程图都需要调整，使依赖尽量向核心（Owner）偏移。
核心域：Owner。生成报价行情的对象，报价行情的所有者。
子域：报价簿子域、资产子域、群组子域、预警子域、监控子域、报价明细子域。
实体：机构、群组、全市场、报价单、报价簿、报价明细、资产信息。
值对象：报价簿规则、报价簿ID。
领域服务：机构服务、群组服务、行情计算服务、行情聚合服务、报价预处理服务、仓库服务。
第三步：聚合
根据前面的识别出来的各类对象初步构造出模型。
待续....
Actor是Actor.class模型的核心，怎样在DDD的架构中使用Actor？
Actor的能力和Service相似，服务是无状态的，但状态却是Actor模型的特点。一个无状态的领域服务一般使用单例模式，而当一个类有了状态，就好像一个物体有了生命，“我是谁？我在哪？”这些也都成了它所需要关心的问题。我们需要维护服务列表、制定路由规则、实现服务发现功能...写到这，我们可以发现这些和微服务的服务治理非常相似。所以，我们可以建立我们的“注册中心”封装select,create,actorof等Akka的操作来实现服务发现，还能在里面提供限流、熔断、合并等等扩展。
面向对象
DDD是一种方法论，它的本质还是面向对象的思想。DDD在OOAD的基础上提炼演进出了一套架构设计理论。帮助我们，使我们能更容易的以面对对象的思想来设计工程。DDD的设计也需要遵循OOAD的SOLID原则。
Effective Aggregate Design by V***ghn Vernon
The Clean Code Blog by Robert C. Martin (Uncle Bob)
Reactive-Systems-Akka-Actors-DomainDrivenDesign
复杂度应对之道 - COLA应用架构
领域建模
描述
领域建模可以理解为对要解决的现实中的业务问题进行归纳、需求分析的一个过程。领域模型是领域类或者是业务实体的可视化展示，可作为是一种将业务人员需求转为技术层面向对象设计的沟通交流工具。（不要和DDD混为一谈啦）
价值和目的
建立开发和业务都能理解的统一语言，建立系统的服务地图，识别应该重点投入的核心领域。
适⽤场景
完成场景识别与流程设计之后，适用需要拆分的遗留系统或需要建模的新系统，通常在详细方案设计阶段进行。
过程步骤
***步， 业务场景分析
根据业务流程或用户旅程，识别出需要重点分析的 领域场景 。这一步可参考上一篇指南“场景与流程设计”。
第二步，识别关键领域事件
通过头脑风暴的方式，团队成员一起发散寻找核心域中业务关心的事件。将所有事件记在橙色便签上，按时间顺序贴到看板，形成一条或多条团队认可的事件流程。识别事件要点如下：1.根据事件因果关系来识别各自的前置事件和后置事件。2. 在识别事件过程中，发现事件流分支；出现分歧和争执的事件；需要强调的事件或对应的领域逻辑的事件需要用粉色便签标记好，重点关注。
[if !supportLists]Ø [endif]事件命名时需要充分沟通交流，提炼出统一语言。如订单已创建,(OrdeCreated)，即业务名称+动词过去时态的形式。
第三步、识别决策和命令
接着以事件为线索进行反推，是可以找到触发事件的命令及命令的发出者的，领域事件触发来源包括：角色（触发事件的人）、策略（触发事件的规则）、外部系统、事件（即事件的当前事件）。以此完善核心子域的领域事件的实际业务场景。 如下图所示：
第四步、识别业务实体
接下来要根据决策和领域事件之间的关系找出业务主体。例如：在“订单已创建”的领域事件与“提交订单”决策之间抽象的业务主体有可能是“订单”。这里有两个方式找到实体：
找决策与事件中的名词，并通过上下文场景验证业务概念的合理性。
结合决策和事件，补充并定义聚合根/实体/值对象。
第五步、 划分领域事件中核心子域
接下来要将已经识别出的领域事件进一步划分为子域，每个子域对应一个更小的问题域或更小的业务范围。划分出来的多个 核心子领域 构成整个业务领域中的核心问题域 。
第六步、识别限界上下文.
划分核心子领域后，用限界上下文明确模型要解决的问题，每个限界上下文专注于解决某个特定的子域的问题，识别限界上下文的过程方法是基于已有的问题域聚合进行划分，主划分思路如下：
以产品愿景为前提，围绕某个业务价值进行聚合建设。
将业务能力相似的问题域 聚合 放到一个限界上下文中。
打开问题域聚合，发现问题域中有二义性的部分，将其分解成多个聚合，划分到不同的限界上下文中。
根据组织结构与团队结构，将不同团队所负责的业务能力放到不同的限界上下文中。
考虑技术约束，包括：技术异构与语言异构，非功能需求，技术限制等。
第七步、 识别上下文映射
首先识别跨界限上下文之间的相邻事件关系，其次是事件之间是否存在直接触发关系。最后判断：前置事件为下游为D表示依赖方。后置事件为上游U表示被依赖方 。 完成上下文映射识别后，即可得到领域分析模型。
常见工具
事件风暴：是事件风暴由 Alberto Brandolin i提出，是一种在领域驱动设计环境中的研讨会格式，可让您快速分析复杂业务领域,完成领域建模的目的方法。
关键技巧
“不忘初心” ，在划分核心子领域的时候，以业务价值聚合建设，识别核心域。
“避免分布式单体” 如果你想研究篮子，就不要把鸡蛋打碎。同样每个子域对于解决某个特定的问题，如果问题的再分解后，边界更加混乱，建议先不分解。
交付物示例一
《函数响应式领域建模》pdf下载在线阅读全文，求百度网盘云资源
《函数响应式领域建模》百度网盘pdf最新全集下载:
链接：
?pwd=7n8p 提取码：7n8p
简介：传统的分布式应用不会切入微服务、快速数据及传感器网络的响应式世界。为了捕获这些应用的动态联系及依赖，我们需要使用另外一种方式来进行领域建模
运用四色建模法进行领域分析
领域建模有很多种方法，对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我们经常听到这样一个问题：
这听起来是个合理的质疑，但实际上却不是那么有道理。首先我们需要明白建模的目的是什么？如果仅仅是为了描画问题，那么并没有什么对错之分——仅仅是立场和角度的差别；而如果是为了企业业务系统而进行建模，那么这个问题应该变为：
我想用下面这个例子来简要的回答一下这个问题。
在开始分析和建模之前，我们需要知道企业业务系统的目的是什么；而企业业务系统的目的往往跟决策者或者管理的诉求相关。我们现在需要移情到一位管理者身上，看看他的诉求到底是什么。
现在假想你是一家在线电子书店的COO。某天，有一位顾客向你投诉，说他订购的书少了一本，并且价钱算错了，他多给了钱。在你承诺理赔之前，你需要核对一下这位顾客说的是否属实。那么这个时候你需要知道什么样的信息才能做出准确的判断呢？
简单来说，你需要知道这位顾客订购了哪些书籍，付了多少钱以及书店到底为这个顾客送了哪些书籍。不幸的是，由于科技不够发达，你无法直接驾驶时光机器回到从前去亲眼看看发生了哪些事。但幸运的是，你并不需要会这么做，你只需要看看这位顾客的订单，和网银的支付记录以及你们书店交给EMS的快递单存根，就应该知道这些信息了。
你找到了订单和EMS快递存根。发现这位顾客是在三天前订购的书，而你们在前天就已经将书邮寄出去了。并在订单上看到这位顾客一共订购了7本书，但是在EMS的快递存根上，并没有任何书籍的信息，只有地址、包裹号、邮费和重量什么的信息。这时候你觉得应该去询问一下配送部门，看看他们做了什么。
在配送部门你根据包裹号查到了那个包裹的信息，果然里面只有6本书。同时你在包裹部门发现了一张延期交货单。上面说明由于缺货，这位顾客另外一本书正在等待发货。
那么剩下的问题就是支付问题了，从网银的记录上看，客户不含邮费一共支付了132.5元。订单上显示的金额也是132.5，显然这位顾客并没有多付钱。
为了保证准确，你重新从网站上选了这7本书，想看看是否也会是这个价钱。但你却意外的发现，以供只需要128.3。仔细辨认后，你发现有一本图书现在是促销。那么现在的问题是，促销到底是什么时候开始的？
你到了市场部，市场部给了你一份近期促销计划。你发现那部书是昨天才开始促销的，也就是说在那位顾客在下单的时候，促销还没有开始。
这个时候，你觉得应该给你的顾客打一个电话致歉，商讨如何后续邮寄的问题，并向他说明促销的事情。
你是否觉得这个COO当得有点累呢？这当然是虚构的。但是从这故事里面我们看到什么呢？
我们对于事件的追溯可以通过对数据的追溯来完成。正如上面这个故事里，你无法回到从前去看看到底发生了什么，但是却可以在单据的基础上，一定程度的还原当时事情发生的场景。当我们把这些数据的足迹按照时间顺序排列起来，我们几乎可以清晰的推测出这个在过往的一段时间内到底发生了哪些事情。
那么为什么这些数据形成的链条能够成为帮助我们追溯业务的营运呢？
因为这些数据并不是随便挑选的。如果我们回顾一下你作为COO检查这个疏漏的过程，你首先选择了订单和EMS快递存根，换句话说，如果订单出现差错，或者EMS快递存根上说明你的确邮寄了7本书，那么这个疏漏的责任并不在你。所以这两个订单实际上是你这个企业法律责任的起点和终点。
当你确定这个疏漏的责任在你之后，你选择审查一些流程执行的结果，比如包裹存根。从而验证一些主要的业务流程执行的结果是否正确。换句话讲，这些数据是支撑你运营体系的关键流程的执行结果。
1.如果我付出一笔资金，那么我的权益是什么？
2.如果我收到一笔资金，那我的义务是什么？
而这些问题都需要业务系统捕捉到相应的足迹才能够回答。所以企业的业务系统主要的目的之一，就是记录这些足迹，并将这些足迹形成一条有效的追溯链。
而作为业务分析师的你，则应该知道哪些事件在运营上是需要追溯的，这些事件都留下了什么足迹。
这些足迹通常都具有一个有意思的特性，即它们都是时标性对象（moment-interval）。发现这些时标性对象就是建模的起点。对于这些时标性对象稍加整理，我们就得到了整个领域模型的骨干。
由于在***步中，我们就将管理和运营目标作为建模的出发点。因此，整套模型实际上是围绕这些“如何有效的追踪这些目标”而建立的，这样的模型可以保证模型支撑企业的运营。
有人提了一个很有意思的问题：为什么你会以一个看上去像极端情况的例子来说明这个建模方法？以我的经验来看，对于业务系统有两个东西是很重要的：1.可追溯性（traceability）和执行效率（efficiency）。这里的可追溯性是指责任的可追溯性（traceability of liability），而通常都是在一些不太好的事情发生之后，才需要对责任进行追溯。所以想一个相对负面的例子更容易帮助我们找到建模索需要解决的问题。
本篇所说的四色法与Peter Coad的四色法并不完全相同，不敢说是发展，仅仅是对Peter Ccoad四色的一种变化吧。
阐述业务建模流程？2，从业务模型到系统模型需要做哪些工作
业务建模（Business Modeling）是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。
根据环境和需求的不同，业务建模工作可能有不同的规模。以下列出了六种这样的场景。
场景 #1 - 组织图
您可能需要构建组织及其流程的简图，以便更好地了解对正在构建的应用程序的需求。在这种情况下，业务建模就成了软件工程项目中的一部分，它主要是在先启阶段执行的。通常，这些工作在开始时仅仅是画出组织图，其目的并不是对组织进行变更。但实际上，构建和部署新的应用程序时往往会进行一定程度的业务改进。
场景 #2 - 领域建模
如果您构建应用程序时的主要目的是管理和提供信息（例如，订单管理系统或银行系统），那么您可能选择在业务级别上构建该信息的模型，而不考虑该业务的工作流程。这就称为领域建模。请参见工作流程明细：开发领域模型。通常，领域建模是软件工程项目的一部分，它是在项目的先启阶段和精化阶段中执行的。
场景 #3 - 单业务多系统
如果您正在构建一个大的系统（即一系列的应用程序），那么一个业务建模工作可能成为数个软件工程项目的输入。业务模型帮助您找出功能性需求，并且也作为构建应用程序系列构架的输入。详情请参见概念：从业务模型到系统。在这种情况下，通常将业务建模工作本身当做一个项目。
场景 #4 - 通用业务模型
如果您正在构建一个供多个组织使用的应用程序（例如，销售支持应用程序或结账应用程序）。一种有效的做法是：从头到尾进行一次业务建模工作，从而按这些组织的经营方式对它们进行调整，避免一些对于系统来说过于复杂的需求（业务改进）。但如果无法对组织进行调整，那么业务建模工作能够帮助您了解并管理这些组织使用该应用程序时存在的差别，并使您更容易确定应用程序功能的优先级。
场景 #5 - 新业务
如果某个组织决定要启动一项全新的业务（业务创建），并将构建信息系统来支持该业务，那么就需要进行业务建模工作。在这种情况下，业务建模的目的就不仅仅是要找出对系统的需求，而且还要确定新业务是否可行。在这种情况下，通常将业务建模工作本身当做一个项目。
场景 #6 - 修改
如果某个组织决定要对其经营方式进行彻底修改（业务重建），那么业务建模通常本身就是一个或多个项目。通常，业务重建分数个阶段完成：新业务展望、对现有业务实施逆向工程、对新业务实施正向工程以及启动新业务。
关于领域建模和领域建模工具的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。