领域驱动设计，让程序员心中有码（四）

#领域驱动设计，让程序员心中有码（四）

----------------------追忆有关分层的古老往事

         我一直认为，程序员也是艺术家，他们撰写的每一行代码，是献给这大好世界的优美诗篇。不一样的人，写的代码也许风格迥异。有的，如春风化雨润物无声，有的，如高山流水，曲高和寡，还有的如旱日春雷，先声夺人。而若是说，代码是诗篇，那么代码的分层艺术绝对是最早映入读者眼帘的序幕了。

         分层，一直以来是一个很是经典的软件工程学问题，提到分层，不管是资深或者新入门的开发者，或多或少都有本身的理解。    

         在8年前，我刚参加工做时，有幸参与了比较多项目的研发和维护过程，这些项目的开发者，大可能是比我年长几岁的软件开发者。在他们的开发习惯中，每每会倾向于直接在代码中写入用户界面、数据库访问等支持代码，甚至有至关一部分状况下，会把代码写入到用户界面中，这意味着在用户界面层，每每会写入大量的代码，说不定会超过上万行代码。我以为能够将这种设计，理解为“单层架构“。

        再后来的项目开始有了一点点改变，这个时候的架构，被成为“三层架构“。在.NET开发史上，三层架构成为一种历史悠久的框架，从十年前开始，一直到今天，依然是.NET开发者最为熟练的技术框架。如图所示，三层架构在客户端和数据库之间增长了一个中间层，将有效的业务规则、数据访问等放在业务层中进行处理。界面层主要使用对数据的绑定渲染，再经过数据层实现数据的提交处理。有的开发者说，三层架构通吃一切项目，彷佛全部的项目均可以用三层架构来套用。然而在实际工做中，每每会忽略了业务逻辑层，业务逻辑每每会放在界面层或数据层中，最终致使界面层和数据层充斥着臃肿的代码，使人难以维护。

 

    

       MVC架构也是一种很是主流的技术架构，这种架构是一种很是优秀的架构，他将用户界面层经过模型层最先来源于上世纪七十年代，为Smalltalk语言所设计的一种模式，许多基于用户界面的架构也受到了他的启发。MVC架构，经过将逻辑、数据、界面显示分离的形式，实现代码的组织，普遍适用于桌面端或网页程序的开发过程。这种架构的特色是耦合性低、重用度高、生产周期短、部署快。可是一样因为缺少明确的定义，以及代码过于集中，致使代码腐化问题很是严重。

 

    

      MVP架构是从MVC架构中演进出来的典型表明，这种架构经过Presenter来处理逻辑，Model提供数据，View负责显示。固然，他和MVC的区别在于，数据的显示每每是经过Presenter来进行的，全部的界面操做也都是在Presenter中实现，这意味着View层，只是单薄的一层。

 

         

    与此同时，开发者们也善于使用存储过程或视图等不一样的方式写入复杂的业务逻辑，期待的每每是若是是代码发生变动时，只需对数据库进行修改便可，而无需去修改已经部署在用户端的大量的代码。  使用存储过程、触发器或视图等方式，时至今日，依然是备受关注的一种实现技术，尤为是面向传统产业开发的项目，例如面向制造业的工业控制系统，要进行程序的部署仍然须要很是繁琐的流程，这意味着用户层的部署相对来讲不方便，而数据库的变更反而更方便。          

　　不一样类型的架构或设计的理念迄今仍深入的影响着开发者的思惟模式和工做方法，并最终或多或少的影响着软件工程的实现。          

　　从高内聚，低耦合的软件工程学基本原则来讲，模块与模块之间的关系，称为耦合，而模块内部的关系称为内聚。而分层的目的，正是为了在知足这个基本原则的前提下，提升代码的可用性和稳定性。过少的分层，意味着代码可读性必然很糟糕，甚至不利于软件的编译分发，而过多的分层，则一样意味着模块的维护将对总体过程代码不便。          

      领域驱动设计认为，若是代码中，与领域相关的内容分散在不一样的部分，那么要进行业务和代码的分析将变得难如下手。对用户界面的简单调整均可能意味着代码逻辑的变化，而想要调整业务规则，可能须要开发者们去排查与之相关的全部部分，例如界面层，数据层，甚至是存储过程和视图，这种过程实际上已经没办法创建可用的业务模型，甚至没办法创建测试用例和单元测试的开展，只能靠开发者凭经验去处理不一样的状况。为了保证代码的可用性，应当尽量的分析理清所使用的技术和手段，程序层次设计应当简单明了，易于理解。          

　　在复杂系统设计中，分层是一种很是不错的理念，其目的是为了更好的实现关注度分离，使设计的每一个部分，既能获得单独的关注，也能维护系统内部复杂的交互关系。领域设计认为，上述提到的几种设计模式，每每是下面四种概念的某种变体。

•     用户界面层（或者表示层），负责向用户显示信息和解释用户指令。这里的用户，既能够是使用用户界面的人，也能够是另一个计算机系统。
•     应用层：定义软件要完成的任务，而且只会表达领域概念的对象来解决问题。这一层实际上负责的是系统与应用层进行交互的必要渠道。
•     领域层（或模型层）负责表达业务概念、业务状态信息以及业务规则。尽管技术细节由基础设施层实现，但业务状况状态的反映则须要有领域层进行控制。领域层是业务软件的核心。
•     基础设施层：为上面各层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件等等。基础设施层还可以经过架构框架来支持4个层次减的交互模式。

        在传统项目中，每每不见得会如此鲜明的划分层次，可是在进行模型驱动设计的关键，正是须要将领域层从复杂的业务代码中抽离出来。在设计过程当中，应当采起如下操做：

    一、给复杂的应用层次划分层次；

    二、对每一个层次进行独立的设计，使其具备内聚性而且只依赖于它的下层；

    三、采用标准的架构模式，只与上层进行松散的耦合。

    四、将全部与领域模型有关的代码放在一个层中，并让它与用户界面层、应用层和基础设施层的代码分开。

    五、领域对象应当把重点放在如何表达领域模型上，而不须要考虑本身的显示和存储问题，也无需管理应用任务等内容。

    六、模型设计的目的是达到含义丰富、结构清晰、业务鲜明。

       适当的分层，每每会经过架构框架的形式予以体现。在项目开发过程当中，咱们一般会使用一些框架，这些框架每每来源于平时项目的积累或者互联网大佬的知识分享。可是这些框架每每不见得彻底符合咱们的项目需求。领域驱动设计认为，好的架构框架既能解决复杂技术问题，也能让领域开发者集中精力去表达模型，而无需考虑其余问题。然而使用框架很容易为项目制造障碍，最终一样会给人形成错误的理解，即，咱们这个项目很简单，并不须要复杂的框架。然而，笔者认为，大部分情形所认为的不需框架的缘由，每每是项目确实很是简单，或者开发者低估了项目的复杂度，或者因为公司短视的观点，而忽略了代码的架构设计和分层与建模工做，这最终致使项目容易陷入泥潭。

　　固然，也一样要克制欲望，贸然选择难以驾驭的框架，反而让项目开发过程变得不可收拾。所以，要选择性的运用框架来解决问题，明智和审慎的应用框架的价值，让开发者专一于核心业务问题的建模工做，才是提升开发效率和程序质量的手段。

 

原文出处：https://www.cnblogs.com/xiyuanMore/p/10166790.html