领域模型

一、 什么是基础平台 基础平台对应于业务应用，主要处理技术问题，是为业务应用提供技术支撑以及技术方案的模块或者组件。其目的是使得应用组件可只关注于业务逻辑，而不考虑或者少考虑技术问题。 基础平台通常包括如下：基础功能，开发类库，开发模式以及开发部署工具。 二、 为何要基础平台 应用系统的设计可以说是将一个业务语言翻译成程序语言的过程，这个过程同时处理两个内容：业务和技术。 1. 学习业务，编写的代码符合用例的流程； 2. 学习技术，编写的代码符合技术平台的规范和要求。 这里不同底层技术的难易度不同，导致学习成本、开发成本和应用成本也不同。同时对于一个有较长生命周期的软件项目或者产品，其依赖的底层技术的升级也会带来相应的维护成不 面对特定领域的软件项目或者产品，其所依赖的底层技术的广度和深度相对稳定，基础平台可以填平或者减少技术层面的鸿沟。 那么，我们就面临另一个问题，即：业界已经存在大量优秀的开源框架，我们为何要基础平台。 首先，大量优秀开源框架可以帮助我们，但是： 1. 优秀的开源框架通常偏向通用性，而面向特定领域的相关特性和功能还不支持；即便有面向特定领域的，其支持的特性还存在一定差异性；同时其未必支持相应的基础设施。 因此需要进行二次开发，以完善所需的基础设施； 2. 优秀的开源框架在通用性支持广泛，提供多种选择，同时还有一定学习成本；而面向特定领域，需要的模式相对固定。

具体来说，前端浏览器：angular.js等MVC框架；后端: REST + CQRS 。 angular.js等MVC框架是指前端浏览器的MVC框架，而不是类似Struts 或SpringMVC之类的服务器端后端MVC框架。 关于后端MVC框架的问题可见《MVC模式已死 》 http://www.jdon.com/38448 和 基于任务的UI(Task-Based UI) 。 服务器端的MVC框架主要问题是粒度太粗，只能适合传统的CRUD简单粗放的应用，当我们的软件系统转向以用户体验为主，而不是以企业自身资源管理为主的模式时，响应式设计必然拥有良好的用户感受，而传统后端MVC固定的框架针对大量客户端并发事件处理无疑是力不从心，想象一下，用户鼠标一移动就可能发出一个事件，这么多事件如果每个都走Model-View-Controller这样一个流程，仅Controller就要编制多少？编程成本极高，维护拓展起来很不方便。 将MVC框架移植到浏览器前端(Rich Client)，则可以巧妙回避以上问题，javascript的函数风格使得其处理事件来得更简单，对于围绕模型的操作则可以使用MVC实现。见： JavaScript大型可扩展的 设计模式 ，而模型则是从后端领域层以JSON方式推送过来。 后端架构是：REST+CQRS，将 REST 和 CQRS 组合在一起成为CQREST架构

目录 什么是微服务模式 单体结构的历程 单体地狱的银弹-微服务架构 扩展立方体和服务 微服务架构的好处和弊端 优点 大型的复杂应用程序可以持续交付和持续部署 每个服务都相对较小并容易维护 更好的容错性 更容易实验和采纳新的技术 弊端 服务的拆分和定义是一项挑战 分布式系统带来的各种复杂性 开发者需要思考到底应该在应用的什么阶段使用微服务架构 服务的拆分策略 识别系统操作 创建抽象领域模型 定义系统操作 根据业务能力进行服务拆分 从业务能力到服务 根据子域进行服务拆分 上帝类的处理 什么是微服务模式 随着网络基础设施的高速发展，以及越来越多的个体接入互联网，在考虑构建支持海量请求以及多变业务的软件平台时，微服务架构成为多数人的首选。微服务架构的出现时服务事物发展规律的：当问题足够大，有足够多的的不确定因素时，人们习惯于把大的问题拆分成小的问题。通过分割，抽象和重用小而可靠的功能模块来构建整体方案。但是当这些小的，可重用的部分多来越多的时候，又会出现新的问题。再相似的阶段，人们遇到的问题也是相似的，这个时候人们需要一些共识，需要用一些通用的词汇来描述问题以及解决方案，这也是人们知识的总结，微服务模式就是这样的总结和概括，是一种可以通用的共识，用于描述微服务领域的中的问题及解决方案。 单体结构的历程 在企业发展的初期，应用程序相对较小，所有的代码运行在一个应用程序中有以下好处

3 月，跳不动了？>>> 一、前言 随着美团外卖业务的不断迭代与发展，外卖用户数量也在高速地增长。在这个过程中，外卖营销发挥了“中流砥柱”的作用，因为用户的快速增长离不开高效的营销策略。而由于市场环境和业务环境的多变，营销策略往往是复杂多变的，营销技术团队作为营销业务的支持部门，就需要快速高效地响应营销策略变更带来的需求变动。因此，设计并实现易于扩展和维护的营销系统，是美团外卖营销技术团队不懈追求的目标和必修的基本功。 本文通过自顶向下的方式，来介绍设计模式如何帮助我们构建一套易扩展、易维护的营销系统。本文会首先介绍设计模式与领域驱动设计（Domain-Driven Design，以下简称为DDD）之间的关系，然后再阐述外卖营销业务引入业务中用到的设计模式以及其具体实践案例。 二、设计模式与领域驱动设计 设计一个营销系统，我们通常的做法是采用自顶向下的方式来解构业务，为此我们引入了DDD。从战略层面上讲，DDD能够指导我们完成从问题空间到解决方案的剖析，将业务需求映射为领域上下文以及上下文间的映射关系。从战术层面上，DDD能够细化领域上下文，并形成有效的、细化的领域模型来指导工程实践。建立领域模型的一个关键意义在于，能够确保不断扩展和变化的需求在领域模型内不断地演进和发展，而不至于出现模型的腐化和领域逻辑的外溢。关于DDD的实践，大家可以参考此前美团技术团队推出的《

架构设计流程 在「 如何建立架构师的立体化思维？ 」这篇文章中， 老兵哥 跟大家一起聊到架构设计涉及业务、技术、系统和时间等几个维度，也知道从技术维度可以将应用分成七层，那具体怎么做呢？今天我们继续来聊聊分层架构的设计流程，以及接口设计方法等内容。通常，我们可以将分层架构的设计流程分解为下列 4 个步骤： 第一步，结合现实情况，将系统划分成多个层次。 第二步，确定层与层之间的关系，梳理出层与层之间的交互接口。 第三步，将功能相近的接口划归到一个模块，确保模块高内聚，对外低耦合。 第四步，在此基础上进一步明晰接口的参数列表。 仅仅四个步骤就完成了架构设计吗？这会不会太简单空洞了呢？各位看官，不要着急，请听蔡老师慢慢道来，每个步骤都有极具可操作性的方法及工具。 图 5 架构设计流程 层次的切分方法 面对一个庞然大物，你该如何下手呢？不用担心，这已经给你准备了庖丁解牛的方法，轻轻松松把一个复杂的大系统变得可以掌控了。 第一刀： 按照这套方法论来进行架构设计，最理想的情况是将 X 轴切分成七层。而第一刀应该先切在业务和领域之间，即通过 API 把两边解耦。交互和业务跟用户关联度高，经常随需求变化而改动，而领域和资源相对比较稳定。 第二刀： 考虑到要完成某些业务功能，系统可能需要调用外部系统协同完成，为了保证领域层相对稳定，我们需要隔离外部系统或数据持久层变化带来的影响

从程序员往架构师转型的路上，蔡学镛老师总结的“四维架构设计方法论”对我颇有帮助，让我对架构设计有了更立体化、系统化的认知，现将学习心得分享出来供需要的小伙伴参考。 这套方法论通过空间（ X 、 Y 、 Z ）三个维度及时间 T 维度将问题域解构成可以轻松应对的小方块，分而治之。同时，空间（ X 、 Y 、 Z ）三个维度联动，专门为单个维度解决不了的问题提供解决方案。时间 T 维度将问题分解到一个时间范围内，分步骤按节奏逐一解决。多维度、立体化、分层次、动态演进，这是我对这套方法论特点的总结。 接下来，让我们进入这个四维的架构时空一探究竟！ 图 1 四维座标系统 前后端维度（ X1 … X7 ） 前后端维度被分解为交互、业务、领域、资源四大层，其中业务可以细分为应用 X2 、框架 X3 ，领域可以细分为服务 X4 、核心 X5 ，资源也可以细分为代理 X6 、数据 X7 ，共分为七个层次。服务 X4 可以实现 API ，如果公开，就是开放接口，调用服务层的接口，通常需要授权。代理 X6 可以实现 SPI ，隔离耦合，避免核心 X5 依赖特定的外部系统或数据库。每个层次做到高内聚，层与层之间做到低耦合。 图 2 X 轴分层结构 在系统实现过程中，可以综合考虑现状， X2 应用和 X3 框架可以不分拆， X4 服务和 X5 核心可以不分拆，待后续时机成熟可以再重构分层

分析与设计的关系： 做正确的事情（分析），正确地做事情（设计）。 面向对象分析： 发现并描述问题领域里的对象或者概念（概念类）。 面向对象设计： 定义软件对象、 以及它们之间如何协作完成功能的（设计类） 面向对象分析与设计基本过程：定义用例→定义领域模型→定义交互图→定义设计类图 领域模型： 问题领域的概念类以及真实对象的可视化表示 ； 领域模型也被称为 概念模型、 领域对象模型、 分析对象模型 来源： https://www.cnblogs.com/juluwangshier/p/12482944.html

在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题，下文是我针对这几个问题根据自己的设计经历准备总结的一篇文章的提纲，欢迎大家一块进行探讨，集思广益。其中提到了领域建模的概念，但未作详细解释，希望以后能够有时间我们针对这个命题进行深入探讨。 1)不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。 2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。 3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性

http://www.cnblogs.com/RunForLove/p/5693986.html 数据库设计的三大范式：为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 　　在实际开发中最为常见的设计范式有三个：第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式；第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中；第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。总结一下，就是： 第一范式(确保每列保持原子性)； 第二范式(确保表中的每列都和主键相关)； 第三范式(确保每列都和主键列直接相关,而不是间接相关)。 　　在目前的企业信息系统中，数据库还是最佳的数据存储方式，虽然已经有很多的书籍在指导我们进行数据库设计，但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题

http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html#!comments 实体（Entity） 实体就是领域中需要唯一标识的领域概念。因为我们有时需要区分是哪个实体。有两个实体，如果唯一标识不一样，那么即便实体的其他所有属性都一样，我们也认为他们两个不同的实体；因为实体有生命周期，实体从被创建后可能会被持久化到数据库，然后某个时候又会被取出来。所以，如果我们不为实体定义一种可以唯一区分的标识，那我们就无法区分到底是这个实体还是哪个实体。另外，不应该给实体定义太多的属性或行为，而应该寻找关联，发现其他一些实体或值对象，将属性或行为转移到其他关联的实体或值对象上。比如Customer实体，他有一些地址信息，由于地址信息是一个完整的有业务含义的概念，所以，我们可以定义一个Address对象，然后把Customer的地址相关的信息转移到Address对象上。如果没有Address对象，而把这些地址信息直接放在Customer对象上，并且如果对于一些其他的类似Address的信息也都直接放在Customer上，会导致Customer对象很混乱，结构不清晰，最终导致它难以维护和理解； 值对象（Value Object） 在领域中，并不是没一个事物都必须有一个唯一标识，也就是说我们不关心对象是哪个，而只关心对象是什么