领域设计模型基础一

       最近在学习领域设计，在此对自己的学习心得加以记录。

       最早接触到领域设计是在15年的时候。当时只是单纯的模仿，对于这种设计模式的概念和理念没有太多的关注。最近在设计新程序的时突然发现这种设计模式对于业务复杂的场景的确有自己的独到之处。领域设计可以将业务抽象成一个领域，对领域进行封装，其他模块只要获取到该领域对象就能够操作该领域的所有业务功能。领域专注于业务。

       设计好一个领域模型有很多的要求，其中最重要的是对于知识的学习和消化。当接手一个新项目时，如果该项目是一个自己从来没有接触或者很少接触的领域，刚刚接手工作必然会一头雾水，这时候就需要去学习该领域的知识，以便自己更好的进行工作和设计模型。这种学习不仅仅时针对于领域工作人员，对于参与这个项目的团队种任何一个人员同样适用。

       软件的核心是一种能力，一种为用户解决领域相关的问题的能力。所有其他特性，不管有多么重要，都要服务于这个基本目的。当领域很复杂时，这是一项艰巨的任务，要求很高水平技术人员的共同努力。开发人员必须钻研相关领域以获取业务知识。在一些项目种，开发人员对学习与自己工作领域相关的知识不感兴趣，技术人员喜欢那些能够提高其技能的可量化问题。领域工作是很复杂的，如果想要做好领域设计方面的工作，就必须学习一些与工作领域相关的知识。然而技术人员更愿意从事精细的框架工作，试图用技术解决领域问题，而且学习领域知识和领域建模的工作交给别人去做。软件核心的复杂性需要我们直接去面对和解决，如果不这样做，则可能导致工作重点的偏离，而这些都需要我们首先去学习相关知识。

        就软件而言，领域模型设计需要团队中各个不同性质属性的人员互相配合和沟通。我们不能设计出一种模型能够满足业务需求，但是软件技术人员却不可能实现；同样也不能仅仅是技术上的高可实现而忽略了业务方面的需求。这就需要我们很好的交流沟通，然而各个领域从业人员的沟通术语千差万别，互相沟通起来并不方便。最好的方式是建立起统一的沟通语言。我们可以通过统一的沟通语言来进行沟通以帮助去获取知识，并消化知识。

       领域模型设计和程序设计之间的联系是不能被破坏的。也就是是说两方的设计人员不能完全隔离。在抽象领域模型的同时，也应对程序设计进行抽象。对于领域模型设计而言，如果整个程序设计或者核心部分没有与领域模型相对应，那么这个模型就是没有价值的，软件的正确性也会被怀疑。同时，模型与设计功能之间过于复杂的对应关系也是难于理解的，在实际项目中，当设计改变时也无法维护这种关系。所以在软件方面的领域模型设计时提倡模型驱动设计。

       模型驱动设计不再将分析模型和程序设计分离开，而是寻求一种能够满足这两方面的单一模型。不考虑纯粹的技术问题，程序设计中的每个对象都反映了模型中所描述的相应概念。这就要求我们以更高的标准来选择模型，因为它必须满足两种不通的目标。

       有很多方法可以对领域进行抽象，也有很多种设计可以解决应用程序的问题。因此绑定模型和程序设计是切实可行的。但是这种绑定不能够因为技术考虑而削弱分析的功能，我们也不能接受那些只反映了领域概念却舍弃了软件设计原则的拙劣设计。模型和设计的绑定需要的是在分析和程序设计阶段都能发挥良好作用的模型。如果模型对于程序的实现来说显得不太实用时，我们必须重新设计它。而如果模型无法忠实的描述领域的关键概念，也必须重新设计它。这样，建模和程序设计就结合为一个统一的迭代开发过程。

        软件系统各个部分的设计应该忠实的反映领域模型，以便体现出这二者之间的明确对应关系。我们应该反复的检查并修改模型，在软件中更加自然的实现模型，即使想让它反映出更深层次的领域概念也要如此。从模型中获取用于程序设计和基本任务分配的术语。程序代码就是模型的表达，修改代码可能就是改变模型。而模型的改变势必会影响到接下来相应的项目活动。所以通常在设计模型时模型设计人员要与程序设计人员密切合作，两方都要对模型设计和程序实现有连带责任。

        我们在通过程序语言来实现模型的时候通常会选择面向对象的编程语言，因为面向对象的语言能够很好的支持建模范式，而且在程序设计领域也是目前最流行的。

        对于模型驱动设计的构造，下面这张图是在一些资料中找到的领域驱动设计语言的导航图，仅供参考：

            

         

         在软件中，专门用于解决领域问题的那部分代码通常只占整个软件系统的很小的一部分，但是通常都比较重要。要想实现最佳的设计构思，我们需要将领域对象和系统中的其他功能进行分离，这样就能够避免将领域概念和其他只与软件相关的概念相混淆，也不会把领域和整个软件系统混为一谈。

          分割软件系统有各种各样的方式，根据软件行业的经验和管理，现有软件设计方面最常用的分离方式是分层，下面是在一些资料中看到的领域分层图，仅供参考：

         

       

        在面向对象的程序中，常常会在业务对象中直接写入用户界面、数据库访问等支持代码。而一些额外的业务逻辑则会被嵌入到用户界面组件和数据库脚本的行为中。这么做是为了以最简单的方式在短期内完成开发工作。如果与领域有关的代码分散在大量的其他代码之中，那么查看和分析领取代码就会变的相当困难。对用户界面的简单修改实际上很可能改变业务逻辑，而想要调整业务规则也很有可能需要对用户界面代码、数据库操作代码或者其他程序元素进行仔细的筛查。这样就无法实现一直的、模型驱动的对象了，同事也会给自动化测试带来困难。程序中的每一个活动都有其自身的逻辑和适用的技术，因此程序本身必须简单明了，否则就会让人无法理解。

        给复杂的应用程序划分层次。在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下一层。采用标准的架构模式，只与上层进行松散链接。将所有的与领域模型相关的代码放在一个层次中，并把它与用户界面层，应用层以及基础层代码分开。领域对象应该重点放在如何表达领域模型上，而不是需要考虑自己的显示和存储问题，也无需管理应用任务等内容。这使得模型的含义足够丰富，结构足够清晰，也可以捕捉到基本的业务知识，并有效的使用这些知识。 最后只要将各层链接起来，就可以组合成想要的程序系统。

        关于领域驱动设计先写到这，后期会接着分享学习心得。下面对本文进行下简单总结。

        本文主要描述一些为什么要使用领域模型设计程序，设计模型前的如何去准备——学习知识。并提供了一些在设计时需要注意的情况，模型设计和软件设计的关系。简单的领域驱动设计的模块架构，分层思想及方式等，都是些最基础的东西，以后的分享会加进一些代码案例及本人对于领域驱动设计的理解。