CloudNotes之领域建模篇：领域模型简介.docxVIP

CloudNotes之领域建模篇：领域模型简介 CloudNotes领域模型还是相对简单的，并不一定需要采用面向领域驱动的设计方法来解决CloudNotes的领域问题。但出于以下几个方面的原因，我还是采用了面向领域驱动的方式来开发CloudNotes： 领域驱动是企业级应用开发的一种指导性模型，以领域模型作为软件开发的中心，符合解决问题的基本思路 现有的企业级应用开发框架对面向领域的开发模式支持得越来越好，如果选用这种方式，可以在CloudNotes中更好地利用这些框架的最新功能，为系统开发寻求新的机遇 自己对领域驱动设计相对比较熟悉，而且也维护了一套自己研发的DDD开发框架Apworks。在CloudNotes中直接复用该框架，可以大大减小开发投入，缩短开发周期 温故而知新，选用DDD来指导CloudNotes开发，可以获取到有关DDD的更多信息 接下来，让我们一起对CloudNote的领域模型作些简单的了解。 基本模型 如果你使用的是Visual Studio 2013/2015旗舰版（Ultimate Edition），那么在打开CloudNotes解决方案后，你可以在CloudNotes.Design项目下，找到CloudNotesModel.classdiagram类图设计文件： 双击该文件，可以打开CloudNotes的领域模型设计视图。到目前为止，CloudNotes的领域模型如下： 咱们暂且不考虑C# class、aggregate root等这些UML构造型，这些内容我会在接下来的文章中详细介绍（顺带会介绍Visual Studio对于模型设计与自动化代码产生的支持）。从该图可以看出，CloudNotes的领域模型还是相对简单的。基本上可以分为三个大部分：笔记、用户以及客户包（ClientPackage）。或许你会考虑，是否可以将这些部分看成是DDD的界定上下文（Bounded Context）呢？ 界定上下文（Bounded Context） 是的，我们可以考虑将CloudNotes的领域模型划分为三个界定上下文： 笔记界定上下文：管理系统中所有的笔记内容 用户认证与授权上下文：管理系统账户、角色以及权限 客户包管理上下文：管理针对所有客户端平台的升级包 从DDD角度看，由于模型被划分为多个上下文，而且上下文中的子模型也都是高内聚的（界定的），因此有可能会产生概念或语义上的二义性，而这又是通用语言（Ubiquitous Language）所不能容忍的。比如，一个经典的例子就是银行系统里“Account” 的概念：一个提供在线服务的银行系统，简单地说可以粗略地分为两个界定上下文：银行业务以及在线服务。对于银行业务而言，Account表示客户的银行账户，而对于在线服务而言，Account则又表示客户的在线登录账号，而且一个在线登录账号下可以承载多个银行账户，好比招商银行一网通账号可以有多个银行卡账户和信用卡账户等。那么在做系统设计的时候，遇到Account概念时，如何保证团队交流的准确性呢？因此，需要在领域模型中有一个能够解除这种二义性的“组件”，负责帮助团队人员在整个领域模型的理解与交流上保持一致。这种“组件”就是平时常说的“上下文映射（Context Map）”。有关界定上下文以及上下文映射的详细介绍，可以参考这篇文章： HYPERLINK /articles/ddd-contextmapping \t _blank Strategic Domain Driven Design with Context Mapping。 当应用程序所需处理的领域变得很大时，引入界定上下文是很有必要的，从实践角度考虑，使用界定上下文不仅可以在一个相对封闭的范围内，使用一个相对较小的子领域模型，而且还可以从一定程度上提升应用程序的性能：比如某个操作只会发生在系统的某个子领域内部，又如较小的领域模型能够减少系统的处理开销。在Entity Framework 代码先行（Code-First）的开发过程中，可以很好地引入界定上下文的概念，以将复杂的领域模型划分成多个相对较小的简单的领域模型，不仅在模型设计还是在性能上，都有着很好的表现。有关这个话题的更多内容，可以参考我之前翻译的一篇文章： HYPERLINK /daxnet/archive/2013/03/22/2976282.html \t _blank Entity Framework模型在领域驱动设计界定上下文中的应用。 CloudNotes的领域模型相对简单，而且虽然目前后台采用的是Entity Framework，但使用Entity Framework并不是必须的，今后有可能会换成其它的数据持久化系统（比如MongoDB），因此也没有按照上面所述的方式应用界定