.NET领域驱动设计—初尝(一：疑问、模式、原则、工具、过程、框架、实践)

• 1.1.疑问
  • 1.1.1.UML何用
  • 1.1.2.领域建模
• 1.2.模式
• 1.3.原则
• 1.4.工具
• 1.5.过程
• 1.6.框架
• 1.7.项目演示

最近在研究DDD很有收获，因此整理出来跟你们分享，共同进步！

咱们在设计业务系统的时候都会存在一个很是棘手而又没法回避的问题“业务扩展性”、“业务灵活性、”面向对象化“，尽管咱们熟练掌握设计思想、设计模式、设计原则等等关于如何设计灵活性的系统设计理论，可是咱们彷佛都没有将它们运用到真正业务系统设计、开发当中去，为何？这样的疑问若是对有心想设计好系统的朋友来讲确定是很早就出现过，只是没法解决，由于咱们目前使用的设计方法是与面向对象设计背道而驰的。

漫长的数据库驱动开发历史，致使咱们根本没法脱离这个环境进行学习和实战。从教科书再到真正的企业项目开发都是先设计数据库而后进行逻辑的编写，大部分的业务逻辑都是存在于UI和数据库【存储过程、自定义函数】中，所谓的三层架构中的BLL层实际上是形同虚设，根本没有起到它应有的做用。

固然咱们不是大师，咱们只是普通的程序员，但愿有一种方法论能引导咱们进行真确的系统设计。在未接触DDD以前，我也同样有着一样的困扰，咱们编写不少的开发框架、组件、插件、服务等等太多太多相似能提升开发效率的功能，梦想着本身的系统能想真正如书上所说的搭积木同样搭建本身的系统，咱们扪心问本身真的能够作到吗？我叹息，很难；

我一直感受复杂的系统设计对我来讲真的没有办法应付，只能凭借细心和对业务的熟悉程度，没有正确的理论引导，那些所谓的大师们的设计思想的书真的对我帮助不大，看了不知道如何进行运用。时至今日我终于能够感受到那种神秘的设计确实能够带领咱们穿越复发的系统设计。固然这条路对刚开始接触DDD的朋友来讲会存在不少问题，恰巧在下有幸接触DDD有点心得，也经过分析了一个小的系统进行DDD的开发工做，因此在这里把本身最近研究的心得和疑惑跟同行们分享，若有不对的地方请多指点。[王清培版权全部，转载请给出署名]

1.1】疑问

在任何一项新技术被采纳以前必需要解决几个关键的问题，这也是咱们程序员考虑使用一项新技术的必须过程，它的出现能解决哪些问题和将会带来哪些问题。DDD当然很好，可是要想把它运用到本身的项目当中去，是须要不少时间和精力来分析它的实施过程和对项目团队的要求。固然人为的因素和外在的环境问题咱们这里不考虑，毕竟那些是咱们没法改变的事情，这里只讨论和咱们密切相关的问题。

1.1.1】UML何用

作程序开发的咱们都知道UML是干什么的，简单的讲它属于一种标准的系统建模语言，便于咱们对系统进行分析和团队之间的合做。既然是语言它的主要做用是沟通，技术人员和分析人间的桥梁。可是到目前为止我没有发现它真正帮助过我进行系统分析和设计，上面已经提过实际上是两种开发方法论偏偏相反，因此致使根本没法集成，就拿UML中的类图来说，咱们都是先设计数据库而后进行开发何来的对象？直接是表驱动，经过一些快速的代码生成器进行界面和一些通用的单表的CDUS代码的生成，程序中根本没有对象的概念，业务逻辑遍及UI层[图1.1]。UML画的类图没法在程序中表现出来，因此它没法在绝大部分的企业中普及。

1.1图

上图假设是一个简单的模拟B2C的基本功能，经过它咱们能简单的了解到咱们的系统开发的问题所在。

以上图中的系统结构，咱们很难知道系统的具体业务逻辑，更别说对系统的扩展性能有保障。这样的结构在开发初期没有什么问题，可是在后期的维护工做中将是费事费力的，最后的项目代码没法进行的很好的阅读，也就没法很好的进行稳定性维护。特别是业务系统，它的需求会变的不少甚至很变态，若是按照这种方式进行维护，那么界面上的代码会愈来愈多，而BLL、DAL中的重复性的功能方法也会急剧变多或者是服务层的相同功能不一样方法参数的代码会愈来愈多。其实到最后也就谈不上什么艺术了，更别说项目进行产品化后上市。

那么UML真的起不到做用吗？或者说咱们真的与UML无缘？固然不是，而是咱们没有使用相关的软件设计、开发方法论而已。按照DDD的思想，咱们是业务驱动开发，先进行领域模型的建立，而后才是数据库的设计。其实只有按照DDD的开发理论来才能最大的保证系统的扩展性和业务整洁性，才能保证项目的良性循环。[王清培版权全部，转载请给出署名]

1.1.2】领域建模

“领域建模”很抽象也很艺术的一个词，它是软件设计艺术中的一个境界。

咱们经常接触面向对象编程、面向对象设计的书籍或者话题，你们都对它有独特的看法，可是咱们始终没有将它用做真正的系统性开发中去。可是在编写框架的时候咱们都能驾轻就熟的进行面向对象设计，为了保证框架的灵活性乃至最大的扩展性就要进行最细粒度的分解、抽象、提取，这些在非数据库系统开发中都没有问题。然而最大的问题出在对象须要与数据库结合，对象的生命周期持久化在数据库中，生也数据库死也数据库。因此这里的问题就是如何在面向对象设计与关系型数据库设计之间平滑的过分持久化。这是领域驱动开发的最大的问题，也是不少面向DDD框架的开发重点。

在上图中咱们目击了以数据库驱动后系统的大体结构，假设咱们须要保证功能模块的最大的扩展性咱们在编写数据库驱动代码的时候，很难抽象出复杂的变化点，由于都是贫血型的业务模型或者说根本不知道变化点在什么地方。并且并非普通的开发人员能发掘到的，固然数据库驱动开发也同样能够进行灵活设计、开发，可是这样毕竟对开发人员要求很高，他须要具有很强的面向对象设计能力，在不污染现有的代码的状况下进行扩展性重构。至少个人经验告诉我很难，并且在需求阶段并无一个完整的大局观，很容易形成头重脚轻。对后期的系统开发进度也很难控制，由于没法肯定每一个功能模块到底存在哪些接口。

因此咱们仍是朝着光明的道路前进，掌握DDD进行系统设计开发。

咱们下面试着用建模的方式对上图中的功能点进行大体面向对象设计，尽可能提取变化点。

【简单用例】

根据上图的基本功能咱们肯定两组用例，第一组是【客户Custom】发起的全部动做，第二组是【后台管理人员Admin】，好比配货部门、订单审核部门等等。这里纯粹是为了演示建模的功能不是特意的项目实践，因此功能简单明了。

1.2图

客户首次进去平台以后确定是须要进行帐户的【注册】,有注册就会有【注销】，这里的注销不是退出系统的意思，而是注销在当前平台的使用，就跟销户是一个意思。

(固然有人会以为注销不妥，电子商务平台是不该该有注销的，这只是主观的设计而已，每一个人的想法不一样因此能够取长补短 ，我以为有一个正面的注销功能很好，可让用户进行使用，到底如何使用咱们这里就不分析了。)

成为正式用户以后就能够挑选本身喜欢的商品进行【下订单】，下订单后就会进入平台运行管理的流程的，客户会随时收到平台发过来的流程信息反馈。因此这里有一个【短信管理】用例，该用例固然会包含 【删除信息】、【读取信息】、【回复信息】包含的子用例。

(固然可能我分析的不够细致或者有问题的地方，因为我也是最近接触UML建模因此可能有点不熟悉，对UML有兴趣的朋友能够参考相关专业书籍。)

1.3图

后台管理人员须要对客户下的订单进行【配送】处理，配送环节将牵扯到【客户信息】、【更新订单状态】、【打印配送信息】用例，对【打印配送信息】

功能须要【发送收货信息】给用户，告知用户货物已经发出。这里还包括一个泛化的用例【物品清单、配送地址】，在【打印配送信息】功能里面须要具体的打印出跟配货信息相关的信息。

（这里提一下UML用例图实际上是经过纵横向的方式来寻找系统的全部功能点，纵向是系统的全部功能，横向是系统的外部调用者。）

【领域模型】

根据上述用例咱们基本能捕获到大体的系统功能，下面咱们经过建立UML类图来描述领域模型。

模型的建立要根据上一步的用例图来进行分析，只要建立的模型能知足用例的全部功能点就已经完成了一个大体轮廓。有些隐藏的模型是须要不断的重构才能逐渐的浮现出来。

1.4图

大体的模型已经建立出来，这只能算是一个基本的草图形式的建模，还有几个过程没有走完，好比：反复的重构、与领域专家讨论模型的准确性、与DBA进行沟通等等，这些都是DDD的整个范畴。

有了领域模型以后咱们基本算是有了一个大体的业务方向，剩下的就是精益求精的过程，不断的去分析深层业务关系。

【场景序列】 

得出了领域模型以后咱们须要对它进行一个基本的验证，也就是看看模型是否能知足全部的功能需求。最经常使用的就是经过序列图来走查场景，对咱们建立的领域模型进行逐步验证。

因为时间关系我这里就不给出全部的序列图了，只给出有表明性的序列【配送】。

1.5图

因为怕截图片太大因此给出关键的序列流程，能表达其意思就好了。

这是经典DDD调用序列，对上面具体的对象不是很清楚的没关系后面有专门的示例进行全面分析。[王清培版权全部，转载请给出署名]

1.2】模式

模式相比你们都知道是什么意思，一些通用的思考问题的思路、解决方法、分析方法。固然在DDD领域也有不少模式供咱们学习和使用，在需求阶段讲解的是行为模式在分析阶段有分析模式，在设计阶段有设计模式，在实现阶段有实现模式，还有宏观的架构模式。

那么在进行领域建模的时候有些前人总结出来的分析模式能够供咱们参考。

1.2.1】四色原型模式

四色原型模式是我接触的第一个分析模式，固然目前也是发现它确实很好用，因此给同志们分享一下。

四色原型模式是能帮助咱们找出业务当中的核心模型，也就是说核型模式应该具有几个比较重要的特征的。

基本上想要根据UML用例图找出领域模型须要使用名\动词法找出大概的模型，而后顺着领域模型一点一点完善、发掘，从而找出相关的实体模型。可是有些实体模型是一眼就能看出来的，就好比上例中的【用户】、【订单】、【消息】均可以定义为实体类型，也就是当前小示例中的核心领域模型。

看一下四色原型模式的结构图：

1.6图

对照四色原型模式咱们很容易发现模型中的核型实体模型，很明显对照上面的领域模型咱们确实都是核心模型。

1.7图

对照该模式咱们会发现这里的商品其实也是核心实体才对，可是咱们能很快发现咱们忽视它了，商品也存在状态和一些值类型才对，好比商品的使用状态是否是没货、商品的详细属性是否是也存在独立的值对象。固然这些要看当前项目需求而定。太范式的设计会带来一些问题，有性能问题、有开发成本问题，这些都要进行详细的讨论才能最终肯定，因此反范式设计就出现了。[王清培版权全部，转载请给出署名]