”理论中的核心概念。接下来我们首先介绍领域驱动设计,然后再详细介绍领域建模。
2004年，美国软件工程师Eric Evans发表《领域驱动设计——软件核心复杂性应对之道》一书，经过近20年发展，领域驱动已成为全球主流的软件工程方法。
认为现实世界是过程的集合，在软件工程早期取得了成功，随着业务领域越来越复杂，而且需求变化难以预测，很快遇到了挑战（复杂性挑战与灵活性挑战）。
认为现实世界的本质是对象性活动，将关注焦点从过程转到对象，关注对象对业务实践活动的反应机制，运用无限与有限、多变与稳定的辩证思想，有效应对了这两大挑战。
是面向对象的实施方略。1980年面向对象理念正式确立，但如何在工程实践中运用这一理念仍然是一个难题，直到二十年后Eric Evans出版《领域驱动设计》。
从面向过程到面向对象，从面向对象到领域驱动，领域驱动是软件工程科学发展历程的自然延伸，是不可阻挡的趋势。
领域建模的产出是领域模型，它封装业务领域的知识（领域知识），包括概念体系、业务规则、动作响应机制、系统行为等等，是软件的灵魂。
在正式建模之前，我们介绍由我们创立的思维引导工具——角色对象图，其包含四个元素。实际的角色对象图远比上面介绍的复杂，为便于理解我们只介绍关键内容。
其中，“系统”是一种特殊的角色，它按照预置的程序执行软件运营方的意志，因而可以视为运营方的代理。
动作：代表现实业务场景中的人(或其代理)实施的活动，在图中以虚线箭头表示，箭头上标注动作的名称和动作发生的顺序，如创建、减余额。
关联：代表对象之间的关系，在图中以连接对象的实线表示，线上标注关联的名称，如订单“属于” 客户。
如果关联本身需要加以说明，如订单包含商品，需要指明订购量、成交价，这种关联称为显式关联。显式关联的表示法，是在表示普通关联的实线上附加一个矩形框（以虚线连接）， 如“订单商品”、“门店库存” ，矩形框中记明关联的详细信息（称为关联属性）。
因为扣减余额前要计算订单金额。所以会发现商品对象和订单对象显式关联订单商品；
因为要知道从谁的钱包扣减余额。所以会发现订单与客户间的属于关联、钱包与客户间的属于关联；
因为库存是特定于门店的，所以会发现门店对象及其与订单之间的派属；
因为库存又是特定于商品的，所以商品与门店之间存在显式关联门店库存。
这样,通过动作分析,我们就把业务场景中的角色、对象以及对象之间的关联提炼出来了。动作、对象、关联就是领域知识。领域知识还包含业务规则,在角色对象图中是以动作序列体现的。本场景中有4项业务规则；
①创建订单之后一定要减金额，通过第1-2-3步这样一个动作序列体现；②扣减钱包余额时要登记明细，通过第3-4步体现；③创建订单时要减库存，通过第1-5步体现；④减库存时要决定是否预警，通过第5-6步体现。
传统开发方案业务越复杂成本增速越快，呈现出几何级增长态势；引入领域建模可以保证开发成本呈线性增长。
我们知道，开发任何一项功能都需要领域知识做支撑，一个功能点涉及的领域知识可能不止一项，再加上领域知识之间又有联系，这样就形成了一个网状结构。
我们转换视角，从下往上看左图，一项领域知识实际上要支撑多个功能点，在传统方案中，每做一个功能点都要把这个领域知识编码一次，开发成本就高起来了。而且，如果发现做错了，就不会只改一个地方，可能要改三个地方、五个地方，甚至十个地方。这样，开发成本就呈现出几何级增长。
传统开发方案业务越复杂成本增速越快，呈现出几何级增长态势；引入领域建模可以保证开发成本呈线性增长。
引入领域建模之后，我们把领域知识统一提炼出来，构成一个共同的底层，在底层之上再来铺设功能点。增加功能点的时候，就不用重复写这些领域知识，增加的成本仅仅只是这个功能点的成本，而且需要修改时也只需要改一个地方，这样开发成本就呈现出线性增长。
功能实现不了绝大多数不是技术原因，而是业务理解错误导致了内在逻辑冲突；引入领域建模可以有效规避此类风险。
产品经理的业务模型传递到技术团队的过程中存在信息衰减和误差，导致后续有些功能实现不了；引入领域建模后，双方使用同一模型。
传统开发方案往往要等到项目后期才能发现深层次的业务理解缺陷，修改时牵涉面很广，浪费大量时间。引入领域建模，可以在项目初期避免业务理解错误。
传统开发方案下，需求变动往往引起代码大范围修改，严重时甚至会导致项目烂尾。领域建模将业务领域知识抽取出来形成模型，知识是稳定的，因而修改只涉及到应用层。
一般来说，软件是由4个层次组成的（左图）。领域建模把稳定的领域知识抽象出来，作为第三层；在这个层次上铺设第二层就是应用层。应用层是可以灵活应对变化的，因为它的代码量较小，而且不涉及深层业务逻辑，改起来很方便。这里运用了辩证法的思想，就是分离变与不变、分而治之思想。
但是，变与不变在现实当中不是那么泾渭分明的，而是混杂在一起的。从表象上来看它是变化多端的，但是深层次地来看它又是稳定的，所以分离它们需要用到抽象思维。抽象思维是领域建模的核心思维，是领域建模的灵魂。接下来，我们用一个例子形象地讲解怎么运用抽象思维。
在婚礼活动中，主持人为营造氛围会引导宾客玩游戏，比如说发弹幕就有机会中奖，或者红包雨、数钱等等。这些游戏当然是事先由程序员开发出来的，对于小白程序员来说，他可能会每个游戏开发一套程序，每增加一个游戏就重新开发一次。但有经验的程序员是不齿于这样做的，他要做一定的程度的抽象。
第一个维度是参与方式，可以分成两类：一是口令参与(比如说弹幕抽奖游戏，主持人宣布一个口令，宾客将口令发送到弹幕流就参与了游戏)；二是直接参与，即扫二维码就可参与。
第二个维度评奖方式，也可以分为两类：一是随机抽取，如弹幕抽奖游戏，它是从参与者中随机挑选中奖者，不评价他们在游戏中的表现；二是得分排名，如红包雨， 抢到钱多的人中奖。
按这两个维度排列组合可以得出4种类型，然后根据不同的类型编写不同的代码（称为条件逻辑），新增游戏时只需要判定它属于哪个类型就可以了。
①得分排名不一定是正着排，有可能反着排，如寻宝游戏，肯定是花时间最少的得奖；②评奖逻辑通常是事先规定中奖人数，按得分排序后取前几位，但如果允许并列得奖，那事先就不能确定中奖人数；③计分方式通常是累积分值，如“红包雨”游戏，每抢到一个红包就累计一次金额，但很多时候不是这么简单，比如我们把评奖规则改成“面额最大者得奖”，这时就不能累加了；④很多情况下分数很难计算，比方说评奖规则改为“抢到红包金额相同者，面额大者得奖”，这样就不能简单积分了，需要用一个比较复杂的数学函数来把这个分数给算出来；⑤更极端的情况是没有办法计分，比方说评奖规则改为“抢到100元面额者得一等奖，抢到两张50元者得二等奖，抢到零钱凑足100元者得三等奖”。
遇到上述情况就需要修改程序，增加条件分支。程序员都知道一句俗语，“改的越多，bug越多”，而且改来改去改成了一团乱麻，一旦程序员离职，谁也不愿理这团乱麻，项目就没有生命力了。
通过上述分析可以发现，原来这种抽象方式实际上是不好的，它不是真正的抽象。
真正的抽象是怎样的呢？我们需要引入两个抽象的概念，一个是“评奖方案”， 一个是“绩效方案”。我们不需要知道这两个方案的具体内容是什么，只需要基于这两个概念把基础框架设计出来。任何一个游戏不管它的玩法怎么样，运行的基本框架是一样的。
首先，主持人发起一个游戏活动，这个游戏活动所依赖的游戏程序是事先由程序员开发好的，预置到系统里面的。然后，宾客参与游戏，实际上就是在游戏活动跟宾客之间建立一个关联(显式关联)。
接下来就开始玩游戏。玩游戏的过程当中，系统要记录他在游戏当中的表现。这个时候又有点难题，每个游戏玩法不一样，表现的评价方式肯定是不一样的，类似于公司，公司有不同的岗位，每个岗位评定绩效的标准是不一样的，所采用的指标是不一样的。所以这里要引入第三个概念绩效指标，每个游戏不有不同的绩效指标，系统根据 绩效方案记录每个指标的值。
游戏结束时，系统根据记录的绩效指标值和评奖方案进行评奖。
上面提到的评奖方案、绩效方案和绩效指标的具体内容，是特定于游戏的，需要由程序员在开发具体的游戏时设定。但不管具体内容如何，上述基础框架是不变的、恒定的，它就是我们运用抽象思维从业务场景中抽取出来的领域知识。
特别说明：领域模型的物理形态是源代码，这些代码在传统开发方式下也是需要编写的，因此领域建模不会增加编码工作量。而且它实现了高效复用，可以显著减少编码量。
领域建模是一项极富挑战性的工作，被称为一项不可传授的技能，合格建模师极度稀缺，是企业践行领域驱动的主要障碍。
经过十五年潜心研究，我们创立了一套独特的领域建模方法，建立了行业领先的领域建模能力，并且大大简化了建模师的培养过程。
企业践行领域驱动的另一大挑战来自于对象持久化。领域模型在计算机内运行时会产生一个对象系统，为了防止数据丢失，需要实时地将该对象系统保存到数据库，这个过程称为持久化。在执行业务逻辑前需要从数居库将对象调入内存，这个过程称为反持久化。
持久化与反持久化的需求，在领域驱动理念提出之前就已存在，当时的对象系统比较简单，因而并不是一个技术难题。但领域驱动带来了新的挑战。
领域驱动将领域模型视为软件的核心，它要求模型全面、深刻地反映现实世界，封装业务领域中的对象体系和协作机制，因而其领域模型必定是复杂的。这样的模型在运行期间生成的对象系统异常复杂，这就对持久化与反持久化技术提出了新的挑战，现有持久化框架(如EF、Hibemate等)均无法支持。
传统软件比较简单，只需要用单个数据库作为持久化容器；进入互联网和大数据时代后，软件用户量和数据量剧增，需要用多个、多种类型的数据库 构成一个复杂的存储体系。Obase目前是唯一一款面向复杂存储架构的持久化框架。
传统面向对象工程方法把建模重心放在设计阶段,概念建模的成果不会直接运用到最终代码,而是经由技术人员转换、取舍,这样就造成了信息衰减,一些分析人员花了大量精力得到的领域知识被丢弃了。
我们将概念建模作为重点,得到概念模型后,到技术阶段只需要做一些简单的技术加工就可以得到最终模型。
传统开发方案下,产品经理和项目经理经常出现分歧甚至矛盾,产品经理觉得很简单的功能项目经理认为实现不了。原因在于产品经理构建的业务模型向技术团队传递时出现了信息衰减,双方使用的模型不一致。
我们将产品流程与技术流程融为一体,产品原型设计与技术模型的设计都建基于前一个阶段(分析阶段)得到的概念模型,这样就从根本上解决了模型不一致的问题。
应用于土壤检测全流程管理，包括客户在线下、样品接受登记、制订检测方案、监控检测仪器、读取仪器结果、生成检测报告等。
为网站主提供文件存储与直链服务,已稳定运行十年。目前数据库单表记录数已过亿,存储容量达到PB级。
在杭州和武汉建立异地多活数据中心,全国主要城市建立四十多个计算节点,并发请求峰值达1.3万次/秒。
采用专业传感器收集电器、消防设施等设备的实时数据，利用历史数据训练灾害预测模型，预测建筑物发生火灾的可能性。
同时建立多维数据模型，从地区、时间、建筑物类型、灾害类型等多个维度评估安防态势。
面向礼宴服务商的营销、管理软件套件，属于SAAS平台，不需要本地化部署。包含以下组件：
--自助建站工具，支持零代码方式创建企业官网、小程序和WAP网站；--咨询管理系统，支持从客户咨询到成交、再到售后全流程管理:--宴会厅档期助手，用于管理宴会厅的档期，为订单分配档期；--现场互动娱乐，用于宾客在宴会现场参与互动游戏，活跃气氛；--分销管理，宾客可申请成为服务商的分销员，促成交易后分成。
适用于婚礼等活动现场的互动娱乐平台，主持人现场开启游戏，宾客实时参与，系统根据表现评选中奖者;宾客还可购买虚拟道具向新人送祝福。
根据宾客的参与行为分析其社交偏好，利用推荐机制促进宾客建立社交关 系。并开发一个电商平台，供婚庆供应商入驻，打造婚庆领域的垂直电商平台。
适用于按单生产模式的订单全流程管理系统，从下单到货品出库提供全流程信息支撑，核心节点包括订单分派、生产CQ9电子进度跟踪、实时进度通知、物流跟踪等。
自营型电商平台，经营的产品是格林凯尔公司生产的特色化肥，化肥的配方是根据不同地区(具体到县)的土壤、气候、特色作物和作物生长阶段定制的。
公司在各地建立服务站，服务站的主要功能是为下单的农户提供配送服务 (农户自提或送货上门)。服务站的库存由公司调拨。 在平台运营过程中，会开展线上线下结合的促销活动，如推荐客户返现、 团购、抽奖等。
Lotus的意思是莲花。自古以来莲花就给人以纯洁、高雅的形象，宋代哲学家周敦颐颂其“出淤泥而不染，濯清涟而不妖”。软件工CQ9电子程的一大痛点在于代码混乱、不忍直视、难以维护，严重束缚着项目的生命力。希望在我们的努力之下，不管业务多么复杂、需求变化多么大，领域模型都能如莲花一般独守一份洁净、优雅，持续为项目赋予生命力！
