这篇文章主要介绍“什么是领域驱动设计”，在日常操作中，相信很多人在什么是领域驱动设计问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”什么是领域驱动设计”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
思考： 理解领域domain，就要从业务说起。
软件设计中常听到的一个词是：业务。日常开发中，也有同事会说，要熟悉业务； xxx对业务不熟悉。 业务是什么呢？
业务应该是一个公司或者一个产品独有的核心活动、流程。 云计算而言：对外提供池化的计算、存储、网络能力。浅显一点的是：虚拟机的全生命周期管理。
领域是指跟业务强相关的那部分知识，流程。
领域驱动的核心思想是，以业务为核心。向上对接应用层(Application)，向下对接IO层(Repositroy)。比起传统的分层模型来说，它的粒度更细，要求更高了。传统的分层模型在小型软件场景下可以正常发挥效用，但大部分人去实施时，经常会出现2个问题。
业务层的逻辑跑到了应用层，应用层非常臃肿；
业务层的逻辑跑到了驱动层（IO层），导致产品对驱动层的依赖过强，对后续重构维护造成灾难性的影响。
模型这种知识形式对知识进行了选择性的简化和有意的结构化。
领域的核心就是模型。文中对模型的意义进行了定义。这跟大家处理问题时的方法是一样的，忽略将要矛盾关注主要矛盾。模型大家说的最多的，就是物理模型、数学模型。比如“质点”，现实世界中是不存在的，但这样的模型对于解释物理现象，分析物体受力是非常有意义的，没有质点时，你对一个物体施加一个力，要关心这个力的作用位置，现实世界中作用的位置不同，导致不同的结果。
一个平放的立方块，对侧面靠近底部位置施加一个很大的力，因为力矩的作用，这个立方块会前后翻转。不是牛顿第二定律里描述的，它会加速直线向前运行。
这里又要提一个抽象。抽象就是建模的手段。通过舍弃一些不必要细节，得到一个反应我们关注问题的东西，这个东西就是模型了。
模型是设计实现的总结。
模型直接影响设计；
模型是沟通语言；
模型是浓缩的知识。
思考：
模型影响设计 模型的完备性是最终衡量设计是否满足需求的标准，知识的传递应该是：需求变动影响模型，模型变动影响设计。技术专家一般不会直接去看代码判断你的实现是否有问题，但如果给出了模型，专家可以快速看出你的设计是否存在问题。
模型是沟通语言 模型是设计编码沟通的基础，可以把问题局限在大家都熟悉的一个范围中，提高沟通的效率。
模型是浓缩的知识 这一点与2的描述有点重复。感觉可以合在一起。
补充： 模型可以帮助新加入的成员，快速的理解设计。看到很多开源项目都会在文档中描述设计，但很多项目没有一个合适的模型定义，导致理解与上手比较困难。
软件的核心是提供为用户解决领域相关问题的能力。
用白话说，就是为了实现需求。
这部分作者提出了一个比较普遍的问题：大部分编码人员对于建模技巧和业务知识没有兴趣，这恰恰是实现实现用户需求最核心的技术要求。 进一步的原因是“技术人员喜欢比较直接的，能提升自己技术水平的问题。”
这个原因有2层意思。一个是普通的心理现象，人都喜欢直接看得见的东西；比如年轻时喜欢说爱情，非谁谁不娶（嫁），但最终面对现实时，还是钱重要。因为爱情是抽象的，钱是具象的可以看得到的。对于建模这种抽象的东西，完全没有查一个BUG，学习一门新语言来得实在。
另外一个是，当你想跳槽时。你说你会领域建模，可能面试官对于这部分也没有什么积累，不能判断出你的技术水平；即使是ta恰好也懂，在面试的时间内也很难考查出你的领域能力有多强。相反，问问一些语言的特性，或者操作系统相关的基础知识会比较容易判断你的水平。也就是说抽象的东西没有市场。
大多数混乱的软件领域其实是一项充满乐趣的技术挑战。 创建一个克服这些复杂性的易懂模型会带来巨大的成就感。
到此，关于“什么是领域驱动设计”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
