领域建模的思想和方法大数据与领域建模

文章插图
写在前面：要不要DDD网上关于领域驱动的相关文章数不胜数，但是就跟我一个同事说的，具体落地的到底有多少呢？我们说领域驱动最核心的就是领域模型，一个稳定的领域模型胜过千军万马，然而在当下依然是互联网的时代，业务告诉发展的时期，一切的产品设计和技术都是服务于业务，然而有多少业务是随心所欲闭门造车临时方案的情况，我想程序员们应该是深有体会。于是带来一个问题，业务层面如此的不固定，我们如何跟业务通过领域建模来统一语言，更别说稳定我们的领域模型了（一段时间范围内的相对稳定）。同时在那些不懂技术的老板眼里，他们只关注完成系统的开发通过时间点压榨，哪里管你因为使用了 DDD 而带来的开发周期和开发成本的增加，他们只会认为你技术不行，做这么简单的东西要那么久。好了，吐槽到此为止！
既然没有多少企业实际落地 DDD，那我们还需要 DDD 吗？
我的答案：需要，我们需要一个抓手，任何新系统的开发和老系统的重构乃至系统技术应用架构或者功能架构图，都需要一个抓手，一个切入点，一个可以撬动大家思路的武器，包括微服务的拆分，拆分的理论依据是什么？ by experience ？出于慎重考虑我们需要一个抓手，因为 DDD 可能是一个。
? 然而虽说众多企业并没有实际落地 DDD ，或许因为其书籍和资料都过于高大上，但实际上我们平时的工作中都用到了 DDD 的部分理念和方法。例如聚合，在 DDD 建模种聚合是构建领域模型的基础。那我们在日常技术方案设计过程中多多少少都会涉及聚合，甚至我们在画 UML 类图的时候聚合就是六种关系的其中一种。
? 本篇文章属于软实力的修炼，而修炼内功是程序员的基本素养。
一、模型领域驱动最核心的莫过于领域模型，我们先聊一聊什么是模型？
百度百科解释有很多解释，我们一一理解理解。
模型是通过主观意识借助实体或者虚拟表现，构成客观阐述形态结构的一种表达目的的物件（物件并不等于物体，不局限于实体与虚拟、不限于平面与立体）从这里的描述有几点有必要说明，首先模型并不一定是现实世界真是存在的一个东西，其次模型的建立渠道是我们的主管意识，也就是我们的大脑经过思考形成的，但不是瞎说瞎想，有依据和道理的。当然我们也可以把客观世界存在的事物直接定义成我们的模型，而在当今 MVC 的开发模式下，大部分公司大部分程序员都是如此做的也可能是如此想的。如果软件开发都是如此，那么我们确实是大家嘴里的“农民工” 。
另外我们可以得到的一个信息，模型的范围很大很广，甚至不限形式不限地域和空间。
模型≠商品。任何物件定义为商品之前的研发过程中形态均为模型，当定义型号、规格并匹配相应价格的时候，模型将会以商品形式呈现出来。这句话的描述我觉得至关重要，我们可以理解模型它其实是一种过程性的产物，不是结果的呈现，模型本身还比较靠近业务或者技术化，客户所关心的是完全商业化的呈现。
这就从另一个角度体现了建模的重要性，我们可以直接做拿来主义将一个事物直接映射成模型且一一对应，我们也需要做一些深入的思考和沉淀，好好打磨一下我们的模型。
从广义上讲：如果一件事物能随着另一件事物的改变而改变，那么此事物就是另一件事物的模型。模型的作用就是表达不同概念的性质，一个概念可以使很多模型发生不同程度的改变，但只要很少模型就能表达出一个概念的性质，所以一个概念可以通过参考不同的模型从而改变性质的表达形式。广义的定义告诉我们模型是变化的，而且不是拘泥于一种形式或者某一个单一的模型，甚至有时候非常负责的模型才能让我们理解和明白某一个定义和概念，所以模型本身又是复杂的，而建模的过程又是非常有意思的。

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：

领域建模的思想和方法 大数据与领域建模

领域建模的思想和方法大数据与领域建模