业务建模

一、什么是业务领域建模 　　 这里引用百度百科的解释，业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 二、业务领域建模的设计步骤 　　领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念，确定用户业务的问题域，系统涉及的业务范围等等。 　　1. 从业务描述中提取名词； 　　2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合； 　　3. 从业务实体集合中抽象业务模型，建立问题域的概念； 　　4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系 ； 三、业务领域建模的方法 　　四色建模法是由 Peter Coad 发明的一种建模方法，将抽象出来的对象分成四种原型： moment-interval：这种对象表示那些在某个时间点存在，或者会存在一段时间的，这样的对象往往表示了一次外界的请求，比如一次询价（Quotation），一次购买（Sale）

领域建模有很多种方法，对于同样的问题域使用不同的建模手段得到的模型可能也不尽相同。于是我经常听到这样一个问题：怎么才能保证建模的正确性？ 这听起来是个合理的质疑，但实际上却不是那么有道理。首先我们需要明白建模的目的是什么？如果仅仅是为了描画问题，那么并没有什么对错之分——仅仅是立场和角度的差别；而如果是为了企业业务系统而进行建模，那么这个问题应该变为：如何保证模型能够支撑企业的运营？ 我想用下面这个例子来简要的回答一下这个问题。 在开始分析和建模之前，我们需要知道企业业务系统的目的是什么；而企业业务系统的目的往往跟决策者或者管理的诉求相关。我们现在需要移情到一位管理者身上，看看他的诉求到底是什么。 现在假想你是一家在线电子书店的 COO。突然有一天，有一位顾客向你投诉，说他订购的书少了一本，并且价钱算错了，他多给了钱。在你承诺理赔之前，你需要核对一下这位顾客说的是否属实。那么这个时候你需要知道什么样的信息才能做出准确的判断呢？ 简单来说，你需要知道这位顾客订购了那些书籍，付了多少钱以及书店到底为这个顾客递送了那些书籍。不幸的是，由于科技不够发达，你无法直接驾驶时间机器回到从前去亲眼看看发生了那些事。但幸运的是，你并不需要这么做，你只需要看看这位顾客的订单，和网银的支付记录以及你们书店交给 EMS 的快递单存根，就应该知道这些信息了。 你找到了订单和 EMS 快递存根

一、领域模型 　　　　显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。（类：表示业务概念，通常只包含重要属性，少甚至不包含操作；关联、泛化：表达概念之间的关系）， 　　总而言之：领域模型是描述业务领域（业务实体）的静态结构。 　　　　理论派认为，领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 　　　　实战派认为，领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。是需求分析人员与用户交流的有力工具，是彼此交流的语言。 二、建模 　　　　我的工程实践项目是基于文本理解的的聊天机器人（汽车领域）。 　　　　1.应用域信息 　　　　　　用户通过输入name，开始一个对话，输入汽车相关问题，从聊天机器人处获得回答，根据回答进行评价。 　　　　　　聊天机器人从用户处提取问题，送入模型进行计算，输出预测回答，根据评价进行学习。 　　　　2.重要的程序域及其属性 　　　　　　用户：name， 　　　　　　对话：记录，评价 　　　　　　聊天机器人：name，满意度 　　　　3.UML类图 　　　　　　 　　　　　　 来源： https:

1.什么是业务建模？ 　　是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。其目的是对业务进行建模。这方面的工作可能包括了对业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。而根据环境和需求的不同，业务建模工作会有不同的规模。领域建模就是其中一个。 　　如果构建应用程序的主要目的是管理和提供信息，那么可能选择在业务级别上构建该信息的模型，而不是考虑该业务的工作流程。这就称为领域建模。 　　我的工程实践是关于金融文本挖掘的，当普通用户输入实体名后出现与该实体有关的知识图谱，而后台管理员则是提供该知识图谱。因此，我的工程实践中有领域建模这一部分。下面，进入我的工程实践的领域建模。 2. 来源： https://www.cnblogs.com/ljj18/p/11908142.html

工程实践题目：面向消费电子产品的搜索引擎设计 0x00 业务领域建模，模型由元素和元素间的关系组成，对业务建模的主要是分清项目该做什么，不该做什么，了解目标组织（将要在其中部署系统的组织）的结构及机制。 0x01应用域信息 从用户的角度出发分析： 完成一次信息检索首先需要需要登录到网站，输入需要搜索的关键字内容或者设置检索条件。从返回的搜索结果种选择自己感兴趣的信息，进行各种产品的对比。 项目的业务主角主要是用户。 0x02重要的域 用户：搜索事件的发起者，主要有登录及注册、搜索某产品，对比各类产品的属性，收藏产品 管理员：系统的维护者，负责控制的数据的爬取，建立数据的索引，是用户服务的提供者，其主要属性有：登录、管理爬虫、数据维护、管理用户信息。 用户与管理员之间为相互依赖的关系。 0x03类和对应属性 用户： 　　属性：id、密码、搜索信息、喜好 　　方法：全文搜索、条件检索、产品对比、登录、注销、添加产品收藏 管理员： 　　属性：id、密码、权限 　　方法：发布数据、爬取数据、限制用户行为、清洗数据 0x04图 用例图： UML类图： 来源： https://www.cnblogs.com/pyinal/p/11901548.html

说说概要设计 概要设计是一个设计师根据用户交互过程和用户需求来形成交互框架和视觉框架的过程，其结果往往以反映交互控件布置、界面元素分组以及界面整体板式的页面框架图的形式来呈现。这是一个在用户研究和设计之间架起桥梁，使用户研究和设计无缝结合，将对用户目标与需求转换成具体界面设计解决方案的重要阶段。 概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型，与计算机无关。 你如何划分领域边界 # 【领域驱动设计】浅谈聚合的划分与设计 聚合以及聚合根是领域驱动设计中的重要概念，根据定义，聚合是针对数据变化可以考虑成一个单元的一组相关的对象。聚合使用边界将内部和外部的对象划分开来。每个聚合有一个根。这个根是一个实体，并且它是外部可以访问的唯一的对象。根可以保持对任意聚合对象的引用，并且其他的对象可以持有任意其他的对象，但一个外部对象只能持有根对象的引用。如果边界内有其他的实体，那些实体的标识符是本地化的，只在聚合内有意义（参见《领域驱动设计-精简版》第42页）。从定义上看，貌似针对特定上下文的领域模型来讲，聚合的划分与设计并不那么困难

UML像一个工具箱，里面各种工具都有。您只需要从这个工具箱中选择适合您的项目类型的工具用上就可以，并不需要“完整地”使用UML。有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。 各工作流可以选用的UML元素以及推荐用法如图所示。 不少开发人员并不喜欢用UML，更喜欢在白板上画个自造的草图，似流程图非流程图，似类图非类图，然后说“来，我给大家讲讲”。这样的做法有一个巨大的“优点”——怎么画都是对的，关于这个草图的解释权归“我”所有，同事不好批评我，项目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”，大家就玩不转了。上面这种现象，在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。 但是，这样的做法更像是想通过形式上的丑陋来遮掩内容上的丑陋。动乱年代，数学家在牛棚中用马粪纸做数学推导，不代表就可以因为演算工具简陋而允许自己胡乱使用符号和概念；过去的作家没有电脑，不意味着作家可以随意写错别字和犯语法错误。开发人员故意选择简陋的形式为简陋的内容开脱，就如同作家故意选择不好的纸来掩盖自己文字功力不足的事实，并不是好现象。UML没有强调一定要用多么昂贵的工具来建模，但是，即使您在海边用手指在沙滩上建模，模型依然要概念清晰，而不是以此为理由遮掩脓包。 有的开发人员的

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

人体的需求和设计 如果需求和设计不分，利润就会缩水。从需求直接映射设计，会导致功能分解，得到重复代码。如果从设计出发来定义需求，会得到一大堆假的“需求”。拿自古以来就有的一个系统“人体”来举例。人体对外的功能是会走路，会跑步，会跳跃，会举重，会投掷，会游泳……但是设计人体的内部结构时，不能从需求直接映射到设计，得到“走路子系统”、“跑步子系统”、“跳跃子系统”……人体的“子系统”是“呼吸子系统”、“消化子系统”、“血液循环子系统”、“神经子系统”、“内分泌子系统”…… 确实如此，人体的子系统是各个模块，当你需要完成某个动作时是调用各个模块共同完成的。例如你想跑步就需要“呼吸子系统”“，血液循环子系统”，“神经子系统”和“消化子系统”等等共同合作。而不是你要完成什么动作就需要有什么子系统，那样就会出现一大堆的假的需求。所以应该是这样的： “人体的“子系统”中很多是不能从需求直接映射出来的，需要设计人员的想象力。水店老板要雇一个送水工（即租用一个人肉系统），他只要求这个工人能跑能扛工资低就行，管他体内构造是心肝脾肺肾还是一块电路板。同样，也不能从设计推导出需求——因为人有心肝脾肺肾，所以人的用例是“心管理”、“肝管理”。送水工能这样找工作吗：“老板，我有心脏管理功能，你请我吧！” 很多时候我们说“本系统分为八大子系统……”，其实说的是“本系统的功能需求分为八大需求包……”

1、领域建模Domain Modeling：开发团队获取领域知识的过程 2、进行业务领域建模原因：因为软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。比如，团队中的每个人都在说不同种类的语言。德语、法语、希伯来语等。每次有人发言，其他人完全错误的理解发言者真正想表达的话。系统在开发的过程中，每个人都会以不同的方式解释需求和设计。领域模型是一个灵活的，协作的”工做组件“。它对整个项目进行了细化和更新，从而反映了目前对需求空间的理解。领域建模，其目的是通过建立映射问题空间的常用词汇来解决项目沟通不畅的问题。 3、模型(Model)通常由2部分组成： 1）元素(Element) 2）元素间的关系(Relationship) 领域模型以图形方式显示了所有这些不同的术语如何相互关联。是一个简化的类图，在不同的类（领域对象）之间使用线条进行描绘，以显示它们如何相互关联。领域模型显示领域类之间的聚合和泛化关系（has-a和is-a关系） 4、领域建模（Domain Modeling）/业务分析的主要就是： 　 1）寻找业务对象（Business Object） 2）恰当建立这些对象间的关系 5、如何进行领域建模 1）收集应用程序域信息–关注功能需求，同时考虑其他需求和文档 2）头脑风暴–列出重要的应用程序域概念