业务建模

为什么需要数据仓库？ 传统的数据库中，存放的数据都是一些定制性数据较多，表是二维的，一张表可以有很多字段，字段一字排开，对应的数据就一行一行写入表中，特点就是利用二维表表现多维关系。 但这种表现关系的上限和下限就定死了，比如QQ的用户信息，直接通过查询info表，对应的username、introduce等信息即可，而此时我想知道这个用户在哪个时间段购买了什么？修改信息的次数？诸如此类的指标时，就要重新设计数据库的表结构，因此无法满足我们的分析需求。 在产品脑图中可以很清晰的看到根据业务需求设计所需的字段，因此也导致 数据库是根据业务需求进行设计 。 那么有的会问，为什么一开始就不考虑好这个扩展性呢？为什么数据库一开始就不以数据仓库的形式设计？ 首先数据仓库，从字面上理解就可以感受到这是一个很大的空间，而且存储的物品很杂，里面会存放酱油、沐浴露、洗发精等物品，而数据库是存放酱油、盐等厨房用品，洗浴又是一个数据库。 另外一个就是，国内互联网的发展，一开始大家都是做个软件出来，大家一起用，这个时候只要满足的了需求即可，现今不止是需求还有用户的体验等各种方面，需要根据这些分析指标做调整。 小结： 数据库是跟业务挂钩的，而数据库不可能装下一个公司的所有数据，因此数据库的设计通常是针对一个应用进行设计的。 数据仓库是依照分析需求、分析维度、分析指标进行设计的。 什么是数据仓库？ 数据仓库

实体建模法：根据业务与业务之间的联系建模，一般多用在业务建模和领域建模阶段，当然在没有现成可参考的建模方法我们可以采用此方法。 维度建模法：紧紧围绕着业务进行多个维度的分析，大量的维度预处理帮助我们提高开发效率，减少重复开发，但是缺点也就很明显，字段冗余，且在更改业务的情况下需要重新定义维度的预处理，一般应用在逻辑建模阶段，我们主要在这里进行逻辑开发 范式建模法：由inmon提出的，一般主要应用在关系型数据库中，在数仓也可以应用。具体思想从关系型数据库角度出发，结合业务系统的数据模型，能够比较方便的实现数据仓库的建模，但是缺点也很明显，在灵活性和性能方面效率低下。 https://segmentfault.com/a/1190000012882641 来源： https://blog.csdn.net/weixin_43680708/article/details/100030959

我的工程实践项目是金融文本数据挖掘。 业务领域建模 模型通常由2部分组成： 元素 元素间的关系 因此，领域建模的主要任务是： 寻找业务对象 恰当建立这些对象间的关系 应用域信息 随着时间的流逝，不断有新的新闻发出，旧的新闻文本中包含的信息已无太大意义。所以管理员需要定时的更新新闻材料库以及训练模型，使系统能够挖掘出最新新闻中隐藏的信息。此外，自动生成知识图谱也是必要的，在管理员更新新闻材料库后，系统应及时生成出最新的知识图谱。由于知识图谱的庞大，用户不一定能够发现哪些是最新新闻加入的实体关系。所以系统还应标识出哪些实体关系是最新加入的。 重要的域 本系统最主要的域就是普通用户与管理员。 普通用户：普通用户可以使用系统生成的知识图谱查询某突发事件，通过展示出与该关键词相关实体，以及实体之间的关联。辅助用户对该突发事件做出一个判断。 普通用户属性：登录及注册、查询某事件、下载相关知识图谱。 管理员：管理员主要是维护系统的运行以及爬取最新新闻，更新模型的知识图谱。 管理员属性：登录、更新新闻库、更新模型、查看用户访问情况。 关系：管理员更新信息供普通用户查询。 类以及对应属性 管理员：管理员id，账号和密码、操作记录 用户：用户名以及密码、查询记录、电话号码 爬虫：起始url、爬取方法 新闻：新闻标题、新闻发布事件、新闻url、新闻内容、新闻类型、新闻发布作者 对应类的UML图 来源：

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

注：科比今天要退役了，我是 60 亿分之一，满腹怀念～😭😭😭 前几天看了园友的一篇文章《 我眼中的领域驱动设计 》，文中有段话直击痛点： 有人误认为项目架构中加入 Repository，Domain，ValueObject 就变成了 DDD 架构 。没错，我就是这样，不过准确的来说，并不能称为 DDD 架构，而是我之前经常说的“ 伪 DDD ”设计，后来我还抽离出了一个伪 DDD 设计框架： DDD.Sample ，大家有兴趣的可以瞧瞧，在实际项目的开发中，我用它做过了几个不太大的项目，我个人觉得用起来很顺手，当然并没有真正的 DDD 设计，只不过用了一个空的架构而已，然后冠以”DDD 开发“的名号。 因为之前有过 DDD 设计的痛苦经历（短消息系统），具体表现就是，如果真正 DDD 设计，需要花费大量的时间和精力，可能几天都在思考一个问题或者考虑几行代码的编写，但最后也可能没什么结论或结果，并且这个过程是很艰难和痛苦的，所以我后来就变懒了，懒的去思考项目所表现的业务，也不再考虑如何去设计领域模型，只是在考虑如何让框架用起来更爽，DDD.Sample 前两个应用的实际项目，我都是在完善这个框架，比如 Repository 和 UnitOfWork 的设计等等，所以，关于领域模型的设计，就是一堆贫血模型。不过，后来应用的第三个项目，也就是上一个实际项目，我觉得不能再这样下去了

业务领域建模的概念 领域建模是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。（百度百科） 业务领域建模的原因 分析系统和设计系统不是同一个人，这种割裂导致需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。DDD（领域驱动设计）则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。对于复杂的业务场景，事务脚本很难应对，容易造成代码的“一锅粥”，系统的腐化速度和复杂性呈指数级上升。目前比较有效的治理办法就是领域建模，因为领域模型是面向对象的，在封装业务逻辑的同时，提升了对象的内聚性和重用性，因为使用了通用语言（Ubiquitous Language），使得隐藏的业务逻辑得到显性化表达，使得复杂性治理成为可能。 业务领域建模的步骤 初步建模： 建模也是一个不断迭代的过程，所以一开始可以简单点来，就采用两步建模法抓住一些核心概念：首先从User

邮箱核心业务场景： 发邮件 收邮件 查看邮件 邮箱业务我们关注的核心信息 草稿箱 收件箱 已发送邮件 未读邮件 重要邮件 垃圾邮件 已删除邮件 核心领域模型文字版 共2个模型，如下： 邮件（Mail，聚合根）： ID 标题 内容 附件 是否重要：是、否 发送人邮箱地址 收件人邮箱地址列表（支持多个，逗号隔开） 创建时间 最后更新时间 发送时间 状态：草稿、已发送 支持场景：创建邮件存为草稿、发送邮件、查看草稿邮件、查看已发送邮件、删除邮件 ================================================= 已接收邮件（ReceivedMail，聚合根）： ID 标题 内容 附件 发件人邮箱地址 收件人邮箱地址（单个收件人） 原始收件人邮箱地址列表（发送邮件时填写的收件人列表，逗号隔开，该信息只用于信息查看，当我们要查看这封邮件是发送给哪些人的时候用） 是否已读：是、否 是否重要：是、否 是否删除：是、否 是否垃圾邮件：是、否 接收时间 支持场景：接收邮件、删除邮件、标记邮件各种属性、查看邮件：已接收、是否已读、是否重要、是否删除、是否垃圾邮件 关于邮件投递过程 除了发送邮件、接收邮件外，应该还有一个投递邮件的过程。投递邮件可以由一个独立的投递服务来完成。投递服务负责将当前邮件按照收件人邮箱地址，一个个进行投递，每个收件人邮箱都会收到一个邮件的消息

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

一.领域建模Domain Modeling定义 领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。 二.业务领域建模原因 领域建模可以降低软件和现实世界之间的差异，用真实的业务概念划分职责，目的是实现一个可以高效低成本维护的可持续发展的软件系统。 从领域模型推导到系统实现是一套引导思考的方式，也是一套科学的开发流程。其核心目的在于提供了系统设计的“指导方针”。领域模型必须站在用户需求和业务发展的角度上，既可以用来同客户沟通验证需求，又可以避免模型因实现的考量而带偏（实现成本、遗留系统） 软件工程师需要在不同的领域或不同的项目中工作，来自不同的背景，这可能会影响他们对应用程序域的感知。他们需要领域知识来开发系统。 三.模型(Model)通常由2部分组成： 1. 对象（Object） 2.对象间的关系(Relationship) 四. 领域建模（Domain Modeling）/业务分析的主要就是： 1.寻找业务对象（Business Object） 2.恰当建立这些对象间的关系 3.添加关联和属性 五.领域模型设计的步骤（如何进行领域建模）： 5.1用例分析法 用例分析法是进行领域建模最简单可行的方式。其步骤如下： 1.获取用例描述 既然我们的领域模型指的是问题域模型，那么建模也一定要从问题域入手

业务领域建模Domain Modeling 我的工程实践是《物联网网关智能分析和搜索引擎》，下面是以我的工程实践为例来进行业务建模。 一、Collecting application domain information 当下，物联网行业兴起，物物相联的思想已经渗透到了各行各业，而网关作为物联网行业的硬件基础，也当下发展不可缺少的。但是形式和功能各异的网关对于大多数人来讲都是知之甚少的，因此，本类相关产品便应运而生，旨在帮助客户了解到更全面的网关知识。 二、Brainstorming 1、 定义 物联网(Internet of Things)指的是将无处不在（Ubiquitous）的末端设备（Devices）和设施（Facilities），包括具备“内在智能”的传感器、移动终端、工业系统、 楼控系统 、家庭智能设施、 视频监控系统 等、和“外在 使能 ”(Enabled)的，如贴上RFID的各种资产（Assets）、携带无线终端的个人与车辆等“智能化物件或动物”或“ 智能尘埃 ”（Mote），通过各种无线和/或有线的长距离和/或短距离通讯网络实现互联互通（M2M)、应用大集成（Grand Integration)、以及基于云计算的 SaaS 营运等模式，在内网（ Intranet ）、专网（ Extranet ）、和/或互联网（Internet）环境下，采用适当的信息安全保障机制