业务建模

引言 在讨论DDD分层架构的模式之前，我们先一起回顾一下DDD和分层架构的相关知识。 DDD DDD（Domain Driven Design，领域驱动设计）作为一种软件开发方法，它可以帮助我们设计高质量的软件模型。在正确实现的情况下，我们通过DDD完成的设计恰恰就是软件的工作方式。 UL（Ubiquitous Language，通用语言）是团队共享的语言，是DDD中最具威力的特性之一。不管你在团队中的角色如何，只要你是团队的一员，你都将使用UL。由于UL的重要性，所以需要让每个概念在各自的上下文中是清晰无歧义的，于是DDD在战略设计上提出了模式BC（Bounded Context，限界上下文）。UL和BC同时构成了DDD的两大支柱，并且它们是相辅相成的，即UL都有其确定的上下文含义，而BC中的每个概念都有唯一的含义。 一个业务领域划分成若干个BC，它们之间通过Context Map进行集成。BC是一个显式的边界，领域模型便存在于这个边界之内。领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。 从广义上来讲，领域即是一个组织所做的事情以及其中所包含的一切，表示整个业务系统。由于“领域模型”包含了“领域”这个词，我们可能会认为应该为整个业务系统创建一个单一的、内聚的和全功能式的模型。然而

用例建模Use Case Modeling 一.用例建模的简单描述及优点 用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。 用例建模具有以下的优点： 提供了捕捉功能需求的工具 有助于将系统范围分解成更易管理的小块 提供了与用户以及其他关心系统功能的关联人员进行交流的工具。用例是容易被各种关联人员理解的公共语言 提供了确定、分配、跟踪、控制和管理系统开发活动（尤其是增量开发和迭代开发活动）的手段 辅助估计项目范围、投入和进度 为定义测试计划和测试用例提供了一个基准 为用户帮助系统和手册以及系统开发文档提供了一个基准 提供了需求跟踪的工具 提供了确定数据对象或实体的起点 提供了设计用户和系统接口的功能规格说明 提供了定义数据库访问需求（增加、修改、删除和读取）的手段 提供了驱动系统开发项目的一个框架 二、关键术语描述： 　　用例建模：使用业务时间、发起业务事件的人，以及系统如何相应这些事件来建模系统功能的过程 　　用例图：描述系统与外部其他系统以及用户之间交互的图形

1 业务内容 我们分析的业务是一个电子商务管理系统中的顾客购买商品的案例。 2 识别参与者和用例 参与者：Customer顾客，在顾客购买商品用例中只有一个参与者就是顾客，在这个业务过程中商品管理员并不参与。 2.1 顾客Customer用例图： 　顾客有很多业务活动，其中就包括了购买商品业务。 2.2 购买商品用例。 　下表左侧是用例名称，右侧是系统设置，用过下表我们可以清晰的看到整个购买商品用例的所需条件，操作流程和可选操作流程。 3 顾客购买商品时序图 下面整个顾客购买商品操作时序图，可以看到，用户先要登录然后系统提示选择商品，用户查看商品列表，添加购物车将商品存入订单表后，然后系统提示添加成功。 4 顾客购买商品协作图 下图是购买商品协作图，显示了整个顾客购买商品过程中几个对象的相互协作关系，其中包含了顾客、数据库、登录系统、购物车、浏览商品。 以上就是整个顾客购买商品业务的全部分析。 　　 来源： https://www.cnblogs.com/handson/p/11780923.html

机器学习作为近几年的一项热门技术，不仅凭借众多“人工智能”产品而为人所熟知，更是从根本上增能了传统的互联网产品。在近期举办的2018 ArchSummit全球架构师峰会上，个推首席数据架构师袁凯，基于他在数据平台的建设以及数据产品研发的多年经验，分享了《面向机器学习数据平台的设计与搭建》。 一、背景：机器学习在个推业务中的应用场景 作为独立的智能大数据服务商，个推主要业务包括开发者服务、精准营销服务和各垂直领域的大数据服务。而机器学习技术在多项业务及产品中均有涉及：基于用户画像的智能推送，商圈景区人流量预测，个性化内容推荐，用户流失以及留存周期的预测等。 二、具体开展机器学习的过程 1、原始数据经过数据的ETL处理，入库到数据仓里。 2、上面蓝色部分代表机器学习：首先把样本数据与我们的自有数据进行匹配，然后洞察这份数据并生成特征，这个过程叫特征工程。接下来基于这些特征，选择合适的算法训练后得到模型，最终把模型具体应用到全量的数据中，输出预测的结果。 标准的机器学习工作流：针对业务上产生的具体问题，我们把它转化成数据问题，或者评估它能否用数据来解决。将数据导入并过滤后，我们需要将数据与业务问题和目标进行相关性分析，并根据具体情况对数据做二次处理。 下一步我们进行特征工程。从数据里找出跟目标有关的特征变量，从而构建或衍生出一些特征，同时要把无意义的特征剔除掉。我们大概需要花80

转自： https://www.jianshu.com/p/8378b80e4b21 从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：数据仓库的域模型应该包含企业数据模型得域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。维度建模法（Dimensional Modeling）维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《The Data Warehouse Toolkit-The Complete Guide to Dimensonal Modeling，中文名《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型

原文地址： https://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html 领域驱动设计之领域模型 加一个导航，关于如何设计聚合的详细思考，见 这篇 文章。 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计），简称Evans DDD。领域驱动设计分为两个阶段： 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型； 由领域模型驱动软件设计，用代码来实现该领域模型； 由此可见，领域驱动设计的核心是建立正确的领域模型。 为什么建立一个领域模型是重要的 领域驱动设计告诉我们，在通过软件实现一个业务系统时，建立一个领域模型是非常重要和必要的，因为领域模型具有以下特点： 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分； 领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等； 领域模型确保了我们的软件的业务逻辑都在一个模型中

Martin Fowler在《 企业应用架构模式 》一书中写道： I found this(business logic) a curious term because there are few things that are less logical than business logic. 初略翻译过来可以理解为：业务逻辑是很没有逻辑的逻辑。 的确，很多时候软件的业务逻辑是无法通过推理而得到的，有时甚至是被臆想出来的。这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解。而在具体编码实现时，除了应付业务上的复杂性，技术上的复杂性也不能忽略，比如我们要讲究技术上的分层，要遵循软件开发的基本原则，又比如要考虑到性能和安全等等。 在很多项目中，技术复杂度与业务复杂度相互交错纠缠不清，这种火上浇油的做法成为不少软件项目无法继续往下演进的原因。然而，在合理的设计下，技术和业务是可以分离开来或者至少它们之间的耦合度是可以降低的。在不同的软件建模方法中， 领域驱动设计 (Domain Driven Design,DDD)尝试通过其自有的原则与套路来解决软件的复杂性问题，它将研发者的目光首先聚焦在业务本身上，使技术架构和代码实现成为软件建模过程中的“副产品”。 DDD总览 DDD分为战略设计和战术设计。在战略设计中，我们讲求的是子域和 限界上下文(Bounded Context,BC)

机器学习现在在很多地方都是十分流行，无论现在的你是否从事建模工作，还是你将来想从事相关工作，对于从业者可以从中看出一些同感与意见，对于未来从业者可以了解这个职业到底是做些什么。 话不多说，一个机器学习模型的开发周期一般可以分为： 1、业务需求挖掘（Business insight） 2、数据搜集处理（Data Curation） 3、模型训练开发（Modeling） 4、部署及测试上线（Deployment） 5、模型闭环监控及继续优化（Feedback & Improvement） 本文也是按照这个结构来进行展开总结与思考。 01 业务需求挖掘（Business insight） 当我们接到业务需求的时候，第一件事情需要了解的，就是需求的整体逻辑。一个合理的产品设计通常都是与业务痛点相挂钩的。如果业务提出一个比较空泛的需求，如： 我想要提高一下营销成功率，帮我搞个模型吧。 这个时候，我们需要沉住气,，有的时候数据建模师也需要充当起“心理辅导员”，慢慢引导业务说出实际的业务痛点与需求，好让我们对症下药（当然靠谱且有经验的业务是不会犯这种行为的）。在经过若干分钟的业务了解，其实业务真正想提高的，是 最后的审批通过率 ，而继续了解，发现是由于最近业务的增长，电销人员的人手不足，导致审批的效率低下，而真正有意愿购买产品的客户被营销的可能性降低，导致最终的整体转换率过低。 了解过后

0. 题型 0.1 内容要求 摘要字数在 400 字以内，可以分条叙述，但不允许有图、表和流程图。 正文字数为 2000 字至 3000 字，文中可以分条叙述，但不要全部用分条叙述的方式。 0.2 题目 第一题 介绍主题相关的项目 可以包含以下内容 开发背景 总体需求 采用的技术体制 （使用该技术/方法的、该项目的）动机与期望 介绍担任的主要工作 第二题 理论描述，因主题而异 第三题 如何应用到项目中的，比如用到里理论中提到的哪些概念，又是如何实现的，实施效果又如何。 遇到了哪些问题，又是怎么解决的，实施效果又怎么样？ 0.3 注意 细心审题，问的是什么 备考阶段要专心于自己最熟悉、最复杂、最高级的系统或项目，因此这个系统或项目中自己不熟悉的部分就不要准备了，免得到时候瞎扯。所以后面这种都加上了 删除线 。 1. 软件架构（体系结构）设计 2018，论软件体系结构的演化 软件体系结构的演化是在构件开发过程中或软件开发完毕投入运行后，由于用户需求发生变化，就必须相应地修改原有软件体系结构，以满足新的变化了的软件需求的过程。体系结构的演化是一个复杂的、难以管理的问题。 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。 软件体系结构的演化是使用系统演化步骤去修改系统，以满足新的需求。简要论述系统演化的6个步骤。

对 jBPM 来说，今年最大的事件莫过于jBPM的创建者 Tom Baeyens 离开JBoss了。Tom Baeyens离开的具体原因尚不清楚，但他的离开产生了两个结果：一是jBPM的下一个版本jBPM5完全放弃了jBPM4的基础代码，基于 Drools Flow 重头来过；二是Tom Baeyens加入 Alfresco 后很快推出了新的基于jBPM4的开源工作流系统 Activiti 。由此不难推测Tom Baeyens离开的部分原因：JBoss内部对jBPM未来版本的架构实现产生了严重的意见分歧。更加巧合的是12月1日Activiti5刚发布，紧接着12月2日jBPM5就发布了第一个候选发布版本，jBPM与Activiti之间的微妙关系可见一般。 相关 厂商 内容 Flash Builder 4.5高级版试用版免费高速下载 百度技术沙龙第十七期：富客户端时代的JavaScript框架（8月20日 周六） Hadoop、HBase、MongoDB和Cassandra等技术在当前的企业中的应用 Sybase在线研讨会：云时代的列式数据库——Sybase IQ15.3新特性(8月22日 周一) InfoQ诚聘：策划编辑、项目经理、商务经理等 在这篇文章里，我们将一起回顾jBPM从jBPM3到jBPM5以及Activiti5的发展历程，我们可以清晰的看见jBPM