大数据建模技术，城市规划大数据理论与方法

　　写在前面你想要DDD上无数关于领域驱动的文章吗？但正如我的一位同事告诉我的那样，他们中有多少人真的着陆了？都说我们域驱动的核心是域模型，一个稳定的域模型胜过千军万马。，目前还是互联网的时代，所有的产品设计和技术都是为业务服务的。，我觉得程序员应该深有体会，有多少业务是闭门造车的临时解决方案。这就带来了一个问题，业务层面流动性这么大，怎么能通过领域建模把语言和业务统一起来，更别说稳定我们的领域模型(一段时间内相对稳定)。，在那些不懂技术的老板眼里，他们只关注完成系统的开发，通过时间来压榨，而不考虑使用DDD带来的开发周期和开发成本的增加。他们只会觉得你不熟练，做这么简单的东西要花这么长时间。好吧，就这样！

　　既然没有多少企业真正登陆DDD，我们还需要DDD吗？

　　我的回答是是的，我们需要一个抓手。任何新的系统开发，旧的系统重构甚至系统技术应用架构或者功能架构图都需要一个抓手，一个切入点，一个能撬动大家思维的武器，包括微服务拆分。拆分的理论依据是什么？凭经验？出于慎重考虑，我们需要一个抓手，因为DDD可能是其中之一。

　　不过，虽然很多企业并没有真正落地DDD，或许是因为他们的书本资料太过高大上，但实际上我们在日常工作中还是借鉴了DDD的一些思路和方法。例如，在DDD建模中，聚合是构建领域模型的基础。然后我们在日常的技术方案设计过程中或多或少会涉及到聚合，甚至在我们绘制UML类图的时候，聚合就是六种关系之一。

　　这篇文章属于软实力的修炼，内功的修炼是程序员的基本素养。

　　 1.模型领域驱动的核心是领域模型。先说什么是模型。

　　百度百科有很多解释，我们一一了解。

　　模型是通过主观意识，以实物或虚拟表象的方式客观说明形态结构的物体(物体不等于物体，不限于实物和虚拟，不限于平面和立体)。从这里的描述来看，有几点需要说明。第一，模型不一定是现实世界中真正存在的东西。，建立模型的渠道是我们的主管意识，也就是我们的大脑是通过思考形成的，但不是胡说八道。是有依据的，也是合理的。，我们也可以直接将客观世界中存在的事物定义为我们的模型。在如今的MVC开发模式下，大多数公司的大多数程序员都是这么做的，可能也是这么想的。如果软件开发是这样，那么我们确实是大家口中的“农民工”。

　　我们能得到的另一个信息是，模型的适用范围非常广，甚至在形式、地域、空间上都是无限的。

　　型号商品。任何物体在被定义为商品之前，其在研发过程中的形态都是模型。当型号、规格和对应的价格确定后，型号就会作为商品呈现。我觉得这句话的描述很重要。我们可以理解模型实际上是一个过程产品，而不是结果的呈现。模型本身比较贴近商业或者技术，客户在意的是完全商业化的呈现。

　　这从另一个角度反映了建模的重要性。我们可以直接把一个东西映射到一个模型中，一一对应。我们还需要做一些深入的思考和沉淀，打磨我们的模型。

　　广义来说，如果一个事物能随着另一个事物的变化而变化，那么这个事物就是另一个事物的模型。模型的功能是表达不同概念的属性。一个概念可以使许多模型发生不同程度的变化，但只有少数模型可以表达一个概念的性质，所以一个概念可以通过引用不同的模型来改变其性质的表达形式。广义的定义告诉我们，模型是可变的，并不拘泥于单一的形式或单一的模型。有时候即使是非常负责任的模型，也能让我们理解和明白某个定义和概念，所以模型本身是复杂的，建模的过程是非常有趣的。

　　当一个模型与事物联系在一起时，就会产生一个带有性质的框架，这个框架决定了模型如何随事物变化。这里引入了框架，我们可以嗅到框架的气息，这说明了模型是多么的重要，而当它与现实世界联系在一起时，产生的蝴蝶效应也会预示着事物发展的过程和结果。

　　模型是用来表达现实世界中真实或虚拟的事物。它们被用来表达某些概念，使我们获得某些知识。在未来事物的发展和演变中，我们可以通过一定的框架来控制和稳定事物的发展，从而防止出现超出我们控制范围的情况。

　　，模型属于数据领域，所以谁说我们小学初中高中学的单词量没用？其实功能和用途无处不在，只是说这种话的人不知道罢了。

　　二、场我们来看看什么是场。

　　英文名domain

　　中文意思

　　它指的是特定的范围或区域。我们画出“关键范围”这个词，即领域模型实际上是用范围来表示一些概念、认知和事物。就像我们作为技术PM启动一个项目时，必须在有限的时间内完成某个工作清单中的一项任务。项目管理中最重要的是项目范围。同样，我们这个领域建模最重要的就是确定模型的范围。以下是其他解释，但大致意思差不多

　　一个国家的主权范围。专业活动或事业的范围、种类或部门。学术或社会活动的范围。3.领域模型领域驱动有几个非常重要的概念核心领域、子域、通用领域和有界上下文。

　　核心领域决定产品和公司核心竞争力的子领域，是商业成功的主要因素，也是公司的核心竞争力。从这个定义可以看出，核心域其实就是我们目前业务最直接最尴尬的内容，比如点菜APP，所以它的核心域应该是点餐、管理菜品、发布菜品、评价菜品、点菜。

　　那在这个 APP 里的其他功能比如用户、库存、配料、支付、用户的订单甚至账务这些要么通用域要么是支撑域。

　　通用域顾名思义，具有通用性，在点餐的 APP 中，用户、库存、配料这些就属于通用域，被多个子域所引用。

　　支撑域它是用来解决某一个业务问题，在点菜的 APP 中用户的支付订单、账务、支付就是支撑域，为了解决 APP 支付相关的某一个业务问题。

　　限界上下文的理解非常重要，它也将确定我们领域划分边界。我们在弄清楚哪些是核心域、通用域、支撑域后，我们需要对产生的聚合进行分组，通过业务的内聚性和关联度划分边界，结合上下文含义并给出上下文名称。限界上下文不是跟模型一一对应，可以是多个模型组成一个限界上下文，它的作用可以明确模型有解决的问题，并保持每个模型的清晰。我们讲领域的核心在于确定范围，而限界上下文就是领域模型的边界，也是我们对领域认知的边界。我们常说的高内聚低耦合意思就是在某一个限界上下文内，模型之间紧密关联，而其他模型应该在其他的领域限界上下文中。

　　那为什么说限界上下文跟模型不是一对一的，可以是一对多的？

　　模型不是万能的，模型存在的意义就是描述现实的真实或者虚拟事物，并一定要能够解决现实的问题。世界也是不停变化的，事物也是发展变化的，所以现实情况的种种问题也是复杂多样的，往往用一个或者两个模型也无法能够非常清晰的面面俱到的描述和解决所有问题，这个时候我们就需要把多个模型围起来，形成一个整体来解决问题，对这个整体进行建模。

　　子域可以解决某个特定的问题。

　　四、如何领域建模

　　 网上有各种领域模型的详解，也有很多领域建模的方法和例子，在这里把个人认为比较好理解，比较好实施落地的方法列举出来。其实对于如何领域建模的方法论也不是每次都按部步骤去实现，在某些领域划分不清或者分歧较大的时候，通过对业务流程的重塑也许就找到解决问题的钥匙。

　　 所有的开发工作都离不开业务流程的梳理，然后将业务转化成产品语言，技术将产品设计落地实现。所以第一步就是画出所有的核心业务流程，任何业务也都存在一条稳定的业务流程，而业务流程中节点的产物就是我们的业务骨架。一般我们采用如下形式画出业务流程

　　 这里强调的是核心业务流程，核心业务流程可以觉得我们的核心业务域，同样也可以对我们的界限上下文的确定有一定的辅助作用。

　　 挖成第一步后，接下来就是业务子流程的再分解，一般我们会形成如下形式的图

　　 简单的两部，可以大概确定我们的领域模型有哪些，可以支撑什么业务解决什么问题，哪些是核心域、支撑域、通用域，限界上下文如何执行还需要通过抽象和分析，结合各自的作用进行细致的划分。

　　 有的同行甚至把领域建模的方法成了三字经方法找名词、加属性、连关系。

　　五、就这么结束了

　　 本文没有举真实的案例，并不是从来没有实践过 ，而是我亦在和找到个人认为比较能接手的方法论，用来知道以后遇到的一些情况，也是为了强化和修炼内功心法，作为程序员技术不可丢，只有上层剑法秘籍，没有深厚的内功方法论，如何合二为一具备持续的竞争力呢。在这个浮躁的社会，越是晦涩难懂的东西越需要静下心来好好，现在网络流程叫沉浸式！

　　 在未来我还会一些其他方面更为晦涩难懂的理论，人们总是在找一种平衡点，理论过于深奥读不懂，过于白话那是别人的精华不是自己的，要问自己一句核心竞争力在哪里！