DDD Action：池建强《领域驱动设计和实践》

摘要：本文主要介绍了领域驱动设计的基本概念、要素、特点，对比了事务脚本和领域模型的特点，最后介绍了我们在软件开发过程中的领域驱动设计实践。

引言

软件系统面向对象的设计思想可谓历史悠久，20世纪70年代的Smalltalk可以说是面向对象语言的经典，直到今天我们依然将这门语言视为面向对象语言的基础。随着编程语言和技术的发展，各种语言特性层出不穷，面向对象是大部分语言的一个基本特性，像C++、Java、C#这样的静态语言，Ruby、Python这样的动态语言都是面向对象的语言。

但是面向对象语言并不是银弹，如果开发人员认为使用面向对象语言写出来的程度本身就是面向对象的，那就大错特错了，实际开发中，大量的业务逻辑堆积在一个巨型类中的例子屡见不鲜，代码的复用性和扩展性无法得到保证。为了解决这样的问题，领域驱动设计提出了清晰的分层架构和领域对象的概念，让面向对象的分析和设计进入了一个新的阶段，对企业级软件开发起到了巨大的推动作用。

本文主要介绍了领域驱动设计的基本概念、要素、特点，对比了事务脚本和领域模型的特点，最后介绍了我们在软件开发过程中的领域驱动设计实践。

什么是领域驱动设计（DDD）

2004年著名建模专家Eric Evans发表了他最具影响力的书籍:《Domain-Driven Design Tackling Complexity in the Heart of Software》(中文译名：领域驱动设计软件核心复杂性应对之道)，书中提出了领域驱动设计(简称 DDD)的概念。

领域驱动设计事实上是针对OOAD的一个扩展和延伸，DDD基于面向对象分析与设计技术，对技术架构进行了分层规划，同时对每个类进行了策略和类型的划分。

领域模型是领域驱动的核心。采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是由大量相对小的领域对象(类)组成，这些类具备自己的状态和行为，每个类是相对完整的独立体，并与现实领域的业务对象映射。领域模型就是由这样许多的细粒度的类组成。基于领域驱动的设计，保证了系统的可维护性、扩展性和复用性，在处理复杂业务逻辑方面有着先天的优势。

领域驱动设计的特点

领域驱动的核心应用场景就是解决复杂业务的设计问题，其特点与这一核心主题息息相关：

  1. 分层架构与职责划分：领域驱动设计很好的遵循了关注点分离的原则，提出了成熟、清晰的分层架构。同时对领域对象进行了明确的策略和职责划分，让领域对象和现实世界中的业务形成良好的映射关系，为领域专家与开发人员搭建了沟通的桥梁。
  2. 复用：在领域驱动设计中，领域对象是核心，每个领域对象都是一个相对完整的内聚的业务对象描述，所以可以形成直接的复用。同时设计过程是基于领域对象而不是基于数据库的Schema，所以整个设计也是可以复用的。
  3. 使用场景：适合具备复杂业务逻辑的软件系统，对软件的可维护性和扩展性要求比较高。不适用简单的增删改查业务。

如果不使用DDD？

面对复杂的业务场景和需求，如果没有建立和实现领域模型，会导致应用架构出现胖服务层和贫血的领域模型，在这样的架构中，Service层开始积聚越来越多的业务逻辑，领域对象则成为只有getter和setter方法的数据载体。这种做法还会导致领域特定业务逻辑和规则散布于多个的Service类中，有些情况下还会出现重复的逻辑。我们曾经见过5000多行的Service类，上百个方法，代码基本上是不可读的。

在大多数情况下，贫血的领域模型没有成本效益。它们不会给公司带来超越其它公司的竞争优势，因为在这种架构里要实现业务需求变更，开发并部署到生产环境中去要花费太长的时间。

领域驱动设计的分层架构和构成要素

下面我们简单介绍一下领域驱动设计的分层架构和构成要素，这部分内容在Eric Evans的书中有非常详尽的描述，想要详细了解的，最好去读原版书籍。

下面这张图是该书中著名的分层架构图，如下：

整个架构分为四层，其核心就是领域层（Domain），所有的业务逻辑应该在领域层实现，具体描述如下：

用户界面/展现层

负责向用户展现信息以及解释用户命令。

应用层 

很薄的一层,用来协调应用的活动。它不

包含业务逻辑。它不保留业务对象的状态,

但它保有应用任务的进度状态。

领域层 

本层包含关于领域的信息。这是业务软件

的核心所在。在这里保留业务对象的状态,

对业务对象和它们状态的持久化被委托给

了基础设施层。

基础设施层 

本层作为其他层的支撑库存在。它提供了

层间的通信,实现对业务对象的持久化,

包含对用户界面层的支撑库等作用。

领域驱动设计除了对系统架构进行了分层描述，还对对象（Object）做了明确的职责和策略划分：

  1. 实体（Entities）：具备唯一ID，能够被持久化，具备业务逻辑，对应现实世界业务对象。
  2. 值对象（Value objects）：不具有唯一ID，由对象的属性描述，一般为内存中的临时对象，可以用来传递参数或对实体进行补充描述。
  3. 工厂（Factories）：主要用来创建实体，目前架构实践中一般采用IOC容器来实现工厂的功能。
  4. 仓库（Repositories）：用来管理实体的集合，封装持久化框架。
  5. 服务（Services）：为上层建筑提供可操作的接口，负责对领域对象进行调度和封装，同时可以对外提供各种形式的服务。

当然，DDD中还提出了聚合和聚合根（Aggregate Root）的概念，不过我们在实践过程发现聚合根有问题复杂化的倾向，用传统的聚合、组合等概念去描述领域对象之间的关系更容易理解，所以这里对这个概念就不做介绍了。

事务脚本和领域模型

Martin Fowler 2004年所著的企业应用架构模式（Patterns of Enterprise Application Architecture）中的第九章领域逻辑模式（Domain Logic Patterns）专门介绍了事务脚本（Transaction Script）和领域模型（Domain Model），理解这两种模式对设计和构建企业应用软件非常有帮助，所以有必要介绍一下。

事务脚本：

事务脚本的核心是过程，通过过程的调用来组织业务逻辑，每个过程处理来自表现层的单个请求。大部分业务应用都可以被看成一系列事务，从某种程度上来说，通过事务脚本处理业务，就像执行一条条Sql语句来实现数据库信息的处理。事务脚本把业务逻辑组织成单个过程，在过程中直接调用数据库，业务逻辑在服务（Service）层处理。

事务脚本模式可以简单的通过UML图表示成这样：

由Action层处理UI层的动作请求，将Request中的数据组装后传递给BusinessService，BS层做简单的逻辑处理后，调用数据访问对象进行数据持久化，其中VO充当了数据传输对象的作用，一般是贫血的POJO，只具备getter和setter方法，没有状态和行为。

事务脚本模式的特点是简单容易理解，面向过程设计。对于少量逻辑的业务应用来说，事务脚本模式简单自然，性能良好，容易理解，而且一个事务的处理不会影响其他事务。不过缺点也很明显，对于复杂的业务逻辑处理力不从心，难以保持良好的设计，事务之间的冗余代码不断增多，通过复制粘贴方式进行复用。可维护性和扩展性变差。

领域模型：

领域模型的特点也比较明显， 属于面向对象设计，领域模型具备自己的属性行为状态，并与现实世界的业务对象相映射。各类具备明确的职责划分，领域对象元素之间通过聚合和引用等关系配合解决实际业务应用和规则。可复用，可维护，易扩展，可以采用合适的设计模型进行详细设计。缺点是相对复杂，要求设计人员有良好的抽象能力。

领域模型对应的就是领域驱动设计中划分的领域层，这里就不详细讨论了。

在实际的设计中，我们需要根据具体的需求选择相应的设计模式。具备复杂业务逻辑的核心业务系统适合使用领域模型，简单的信息管理系统可以考虑采用事务脚本模式。

领域驱动设计实践

下面主要讲一下我们在构建企业级应用开发平台中对DDD的实践和扩展。

本人近年来一直在从事企业级应用开发平台的相关工作，GAP平台是我们的一个软件产品，用来解决企业级软件开发过程中复用、快速开发和过程规范等问题。设计这样一个平台，从底层的框架上就应该能够支撑复杂业务逻辑的系统构建，所以我们在大的架构设计思路上采用了领域驱动设计的思路，并根据实际采用的技术和要实现的功能对DDD的四层架构进行了细化和实现：

整个平台采用了JavaEE的技术及其相关的开源框架。系统的核心业务逻辑由Domain层处理，其中的业务服务（BusinessService）负责处理某个相对内聚的业务逻辑单元，同时对内对外提供本地或远程的服务。

下面是对各层的简要描述：

  1. View：展示层，由于GAP平台主要面向B/S架构，展示层主要由web资源文件组成，包括JSP，JS和大量的界面控件，同时还采用了AJAX和Flex等RIA技术，负责向用户展现丰富的界面信息，并执行用户的命令。
  2. Control：控制层，负责展示层请求的转发、调度和基础验证，同时自动拦截后台返回的Runtime异常信息，如果控制层需要与第三方系统交互，可以通过Action做远程的请求。
  3. Domain：领域层，是系统最为丰富的一层，主要负责处理整个系统的业务逻辑。这一层包括业务服务和领域对象，同时负责系统的事务管理。其中业务服务可以提供本地调用和共享远程服务的功能。
  4. Persistence：持久化层，主要负责数据持久化，支持O/R Mapping和JDBC。对数据源的访问提供多种方式。

另外,我们引入了Spring的IOC容器，系统的控制层、领域层和持久化层元素都有IOC容器统一管理，实现完全的接口分离和解耦。同时在控制、领域和持久化层都可以引用日志服务。

我们对领域驱动要素的定义上和原有的命名和含义上稍有区别。

原来的服务（Service），我们定义为业务服务（BusinessService），面向业务服务的架构是GAP平台的核心设计思想，一个业务服务可以由一个或多个领域模型和数据访问对象（DAO）组成，去实现一个完整的业务逻辑单元。业务服务主要负责事务处理和维护各个领域对象之间的关系，同时为上层访问提供本地和远程服务，服务类型包括Web Service，RMI等。

领域对象由实体（Entity）和值对象（VO）构成，实体类具备自己的属性和行为、状态，可以聚合VO，实体类之间可以有聚合关联等关系，可以由数据访问对象（DAO）进行持久化。

持久化由数据访问对象（DAO）实现，不处理业务逻辑，主要负责实体类的持久化。提供多种持久化方式（O/R Mapping和JDBC）。

那么如何在去实现领域驱动设计呢？我们总结了以下四个步骤：

  1. 确定业务服务（Business Service）：根据业务需求和功能模块划分，确定业务单元，每个Business Service是一个内聚的业务单元，覆盖相关的领域对象。
  2. 定义领域对象（Entity， VO）：根据业务单元的业务逻辑定义领域对象，通过UML方法和设计模式描述领域对象。
  3. 定义领域对象的属性和关联关系：确定领域对象的各种属性和各个领域对象之间的关联关系。
  4. 为领域对象增加行为：根据业务需求（系统用例和界面原型等）为领域对象增加行为，并定义哪些方法要被业务服务引用。

案例网上书店

为了更好的理解领域驱动设计，我们基于以上设计方法，实现了一套简单的网上书店系统。

网上书店系统是采用DDD设计思想构建的一个应用系统示例。通过网上书店系统，可以快速理解领域驱动设计。该系统实现网上书店的常用功能：包括浏览书籍、挑选书籍、提交订单、查看订单、自动折扣、处理订单、取消订单等。未登录用户可以浏览和挑选书籍；已登录用户可以提交和查看自己相关的订单；管理员可以处理订单。

经过业务抽象，即使是这样一个简单的业务场景也包含了很多领域对象，例如订单、账户、书籍、购物车、购物项、折扣等，通过分析和设计，我们可以得到这样的设计图（为了查看方便，图中的类隐藏了属性信息）：

BookStoreAction负责处理展现层的请求，并把请求转发给业务服务IBookStoreBS，业务服务负责调度上图中显示的领域对象，处理该场景的所有业务。

其中领域对象和现实业务的对应关系为：

  • Account账户
  • Order订单
  • Book书籍
  • Cart购物车
  • Item订单项
  • Discount折扣

与事务脚本的编程模式不同，领域驱动设计不是把业务逻辑放在BS（BusinessService）中，而是由具备属性、行为和状态的领域对象处理。例如Order类，如果是贫血的POJO，那它内部只有与数据表字段对应的属性以及getter和setter方法，而在领域驱动设计中，则是一个相对独立的、能够处理自身关联业务的领域对象。在本系统中，我们对Order的描述如下：

订单的实现类是gap.template.bookstore.model.Order，类中除了联系方式、邮寄地址等基本属性外，还有以下领域相关的行为：

  1. init(…)，结算时调用方法，根据当前用户与购物车中的Items初始化订单，供用户修改。
  2. submit(…)，提交订单时调用的方法，保存订单。
  3. cancel(…)，取消订单，把订单和相关item的状态设置为已取消，然后委托Dao进行持久化。
  4. dispose(…)，处理订单，首先更新订单项的状态，然后委托Dao持久化订单数据。
  5. reSubmit、setItemsStatus……

通过以上的描述，我们可以看到，Order类基本上覆盖了现实世界中订单这个业务的所有行为和状态，是相对内聚的，这样的特性使其复用性大大增加，即使未来开发新的模块，涉及到订单业务的，可以直接复用Order类。同时在后期维护中，如果我想了解订单的业务，直接读Order的代码就可以了。

从上图中我们还可以清晰的看到各个领域对象之间的关系。Order和Cart都聚合了Item，对应都是1…n，Item聚合了Book，对应关系1…1。Order分别与折扣、账户发生关联和调用等等，整个网上书店的场景就这样描述出来了。

另外，不要忘了BS，除了起到基础设施的作用外（事务管理和服务共享），它还要负责调度和维护领域对象之间的关系。因为总会有些业务逻辑，既不属于这个领域对象，也不属于那个，那这部分业务由谁来处理呢？由BS来处理。例如在管理员处理订单这个场景中，首先需要根据订单信息获取账户，根据账户信息确定折扣率，同时进行余额校验，如果校验通过，就会调用订单对象的dispose方法处理订单，这个场景会涉及到Order、Account、Discount等对象，这样的业务逻辑，应该由BS实现。

IBookStoreDao是数据访问对象，可以被BS调用，用来持久化对象，也可以被领域对象引用，用来持久化自身。

通过以上的描述，我们可以看到，整个设计和实现是优雅、清晰的。业务逻辑没有堆积在BS中，而是分散在BS和各个领域对象中，服务和对象都与现实世界的业务息息相关，无论是对领域专家、开发人员和后期维护人员，都能这种方式中获得自己需要的内容。

总结

我们采用领域驱动设计相对比较早，就我个人的检验和实践而言，DDD对构建企业级应用开发平台和大型核心业务系统的作用是非常明显的，无论是在产品的稳定性、扩展性、可维护性、生命周期等方面都有显著的提升。

但是，由于这样那样的原因（复杂度、工期、开发人员能力限制等等），很多人会不自觉的抵制采用DDD，有时候一个软件项目重写了两次，第二次依然不去做良好的设计。事实上采用了DDD的设计方法，我们的设计阶段已经变得非常轻量级和敏捷了，开发人员只要能够把领域模型之间的关系画出来并描述说明，并与需求人员达成一致，那么做出来的东西基本上是靠谱的。

在技术领域，只有主动的尝试和提升，效果才是最明显的。很多人问过我，如何开始学习和实践XXX，其实很简单，现在就开始吧！

 

原文：http://kb.cnblogs.com/page/112298/

五月 15th, 2012 in Codelife, DDD | tags: | No Comments

DDD Action：大型网站复杂业务持续重构之道——全程领域建模实践

人物介绍：

Jack Chen ——“宠物商店”的首席架构架构师，拥有丰富的软件设计与建模经验，但对新生事物持怀疑态度。

王总——“宠物商店”的总经理，从美国留学后回国创立“宠物商店”网站。一路来唾手可得的成功让他养成了固执专横的行事作风。

Spark —— Jack Chen的大学同学，一家商业软件公司的高级咨询顾问。最近热衷于宣扬“领域驱动设计”的最佳实践。

引子

就象大家所听说过的那些神奇小子创业故事一样，几只从大西洋游回的海龟找到了一个伟大的idea——在互联网上开办在线商店销售宠物。幸亏的是他们找到了投资者而且发展的很不错。但是随着时间的推移，当初“完美”的技术架构随着越来越多的装进篮子的需求后变得不堪重负。作为公司首席架构师的Jack Chen已经被这几个月“鸡毛蒜皮”的需求折磨失眠好几天啦。

Jack Chen周一一早就被兴奋的王总给喊进了办公室，立即就被王总扔出来的idea吓傻了。

“我有一个很cool的想法，我们可以在线为宠物医院提供在线预约的服务业务。而不仅仅是卖掉它们，你知道这意味着什么吗？这是一个年产值上百亿的市场！！！”。

“可是王总，我们的系统不能支持这种非实物的服务预订销售，它可能对我们原有的网站形成巨大的冲击，我们需要三个月的时间对这个业务进行全方面的评估…”

Jack Chen立即就被气势汹汹的王总打断了，“三个月的评估？我需要在两个月内就给我上线这个新业务。我们的投资人非常认可我的idea，并要求我们立即把这个项目上线，它可能会帮助我们提高明年的IPO价格。你明白吗？ DO IT ASAP！”

评估

“好吧，也许这个该死的王胖子是对的。我们这个将技术与业务混在一起的乱摊子也是到了该整理整理的时候。”自言自语发了半小时牢骚后的Jack Chen终于恢复到正常状态上来了，我想我应该看看我们现在是什么样子的，为了支持这个该死的“在线为宠物医院提供在线预约的服务”的需求我们需要做出哪些改变。于是Jack Chen在白板上很快的就画出了下面的Use Case图来。

图1 原宠物商店UseCase汇总图(点击放大)

为了支持“在线预约”这种特殊的产品，它会影响到大部分的Use Case，具体列举如下：

  1. 商品信息需要增加“预约时间”这个属性，客户在下订单时会把它作为标识一个预约的关键要素。
  2. “在线预约”是个虚拟的商品，它可不需要真的需要去检货和包装发货，如果真的那么做啦，我就太傻了。
  3. 每个宠物医院每天都只能接受一定数量的预约，从这个概念上来说，它与实物商品有类似的库存概念。可是我该怎么去表达它们呢？
  4. 最要命的是：我真的要把这些所有受影响的Use Case都翻出来去让它们支持虚拟物品的业务吗？我怎么可能在2个月内完成这些重构？

银弹

了无生趣的Jack Chen在王总的办公室门口徘徊了N圈，还是没有勇气去迎接那一通狂风暴雨般的中英文双语版的羞辱谩骂。“也许事情是有转机的，我好象在哪里听说过有种银弹可以解决这种系统重构的问题的”。“该死，谁把Spark送给我的《领域驱动设计》垫在显示器下啦，他一直在向我布道这本书给他的项目带来的种种神奇改变，也许我也可以试试它的威力”。

“好吧，Spark，我承认你给推荐的书非常棒，你说的也很有道理。我读了它，明白并一些概念——例如：领域分割 、Entity、Service、Value Object…，可我对于该如何去做还是一头雾水。你能不能直接把你从重构项目中获得的最佳实践直接分享给我呢？不然的话，周一王胖子是不会放过交不出答案的我的！”。读完了这本书，Jack Chen觉得很有收获，但又不知道怎么开始，打个电话给领域建模的先行者Spark也许真的是解决问题最快的方法。

“什么，这个问题说来话长？不要紧，我已经在你家门口了，你同我慢慢说”，Jack Chen带着星巴克咖啡+肯德基全家桶+久久鸭脖+谄媚的笑容出现在Spark家门口。

布道

Spark听完了Jack Chen对于现状及需求的描述之后，一幅气定神闲的样子讪讪地说出“这个很简单嘛，你现在需要做的只是这样一些事情：”

  1. 用大比例结构对你的系统进行领域划分
  2. 找出这个需求影响的领域及对外接口
  3. 建立一个适合你们公司的领域驱动设计的技术框架
  4. 按照需求的紧急度来重构各个领域的设计与编码

下面我们就按照这个顺序来实践一下：

一、概要领域划分

Jack Chen立即把自己之前画的Use Case重画了一遍，然后用希冀的眼神看着Spark等待着认可。“你的错误是过于看重Case或者操作者身份，领域的划分不是基于功能或角色来进行的，通常来说我们是将内聚程度较高的Use Case归到一个上下文中。尽量使得领域自闭程度较高，并拥有相同的业务语言环境。例如基于你的Use Case图，我会画出以下的领域”

图2 宠物商店领域通道图(点击放大)

通道图是一个对业务领域建模非常有帮助的工具，它可以同时表达出执行序列与分片的作用。

二、找出受影响的领域与接口

从领域的角度来看，只有商品对外暴露出来的接口是会影响到各个领域，需要优先建立商品领域（ProductDomain）及读取商品信息服务接口（GetProductService）来进行重构。

之外，在【图2】 中用绿色标识出来的Use Case是由于增加支持“在线预约”这种虚拟商品所需要进行代码重构的部分。这部分工作如果工期比较紧，可以优先使用模式的方式来进行代码重构，这样也可以在之后更加容易用领域驱动设计的方法再次重构。

三、建立技术框架

这一点，是《领域驱动设计》这本书没有过多提及的内容。这个需要结合你们公司的原来技术框架用最小化改造成本最大化收益的方式来建立领域驱动的技术框架。下面是一个可以广泛使用的领域驱动的技术框架，可以在这之上增加更多的个性元素形成你公司自己的框架。

图3 领域驱动设计参考技术框架图(点击放大)

这个框架的各个元素基本上在 《领域驱动设计》一书中都可以找到对应的解释，但这里需要解释一下我建立这个框架的个性理解：

  1. 领域对外（页面、AJAX、ESB调用）只暴露领域服务，其它所有领域类都是包内自闭的，对外不可见。
  2. 基础仓库的引入，基础仓库是一个抽象的仓库，它封装了大量常用工具方法、业务对象生命周期维护（实体OR映射、DAO调用）、外部接口调用。可以降低业务仓库不必要的重复编码与复杂性。业务仓库是继承基础仓库的子类。
  3. 基础设施的引用，基础设施是用来承载引用非领域调用的桩，我们在使用领域驱动设计的时候往往是从一个旧的系统重构开始。这时我们不可能要求所有的业务子系统相互调用都通过Domain Service调用，这时我们可以通过Infrastructure优美的把调用封装在业务仓库的业务方法内。

四、重构受影响领域的设计与编码

图4 重构后的商品详情页类图(点击放大)

Spark以商品详情页这个Use Case为例展示了以领域驱动设计的重构类图：

  1. 增加行为表ProductExt用于存储商品的扩展信息，如预约时间段、预约医院。并为表建立一一对应的实体Entity。
  2. 基础仓库Repository通过Infrastructure中的DAO封装了对实体的操作，如create()、update()、delete()、findById()、findList()
  3. 商品业务仓库ProductRepository扩展了基础仓库，客户程序可以用productId为参数，通过ProductVo.getProduct()方法获得商品详细信息的业务实现，由于业务仓库的的公开方法对外返回的都是Value Object，因此不会直接暴露Entity类型给客户程序。
  4. GetProductService服务类通过invoke()服务方法 对外（商品详情页面）提供服务，它通调用业务仓库中的业务方法，并将接口规格化。
  5. 事务配置在DomainService的invoke()方法上，即事务控制以Use Case为粒度进行控制。

尾声

在Spark的帮助下，Jack Chen成功的脱离了困境。现在他正在公司里积极推行自己的领域驱动设计框架，他们公司的网站正在以每三周一次的重构速度快速迭代演进。他象Spark一样，成为了一个领域驱动的布道者。

 

原文：http://www.infoq.com/cn/articles/sb-complex-business-continuity-refact

五月 13th, 2012 in Codelife, DDD | tags: | No Comments

DDD Action：张逸《领域驱动设计实践》

领域驱动设计的关注重心是领域，尤其在面对复杂的领域逻辑时，它总能够帮助我们很好地分析领域。领域驱动设计的基础是领域建模。Eric认为需要和领域专家良好地合作，从交谈中发现通用语言，找到领域的关键词。领域建模是迭代的过程，根据逐渐深入的领域知识来精化模型。不过，领域驱动设计并不排斥其他的分析技术，例如分析模式，或者通过测试驱动开发来引导我们找到问题域的领域模型。

领域建模并非领域驱动设计所独有。在RUP中，领域建模就是一个非常重要的环节。它是一种用例驱动的开发方法，通过获得的用例来帮助分析和设计人员寻找对象，以及对象之间的关系。根据我个人的经验，我喜欢采用两种截然不同的方式来获得模型。一种是用例驱动，一种则是测试驱动。在得到初步的领域模型中，我会尝试利用领域驱动设计的思想为对象分类，找到实体、值对象、聚合以及服务对象，并通过分析对象的生命周期，为不同类型的对象建立资源库和工厂对象。

本文将以一个读者耳熟能详的图书馆管理系统作为我们要分析的领域，尝试讲解如何在项目开发中应用领域驱动设计。我将选择用例驱动的方式来获得我最初的领域模型。简单起见，我先给出分析领域的用例以及用例图。

借书：读者携带要借书籍到借书处。图书馆工作人员首先扫描读者的借书卡，获得读者信息，然后扫描书籍的条形码。如果借阅多本，则扫描多本书籍。扫描时，需要判断当前读者的类型，获得读者可借书籍数。如果借阅书籍超出，则提示。如果扫描失败，允许工作人员手工输入编号。借阅的期限为1个月。

还书：读者携带要还书籍到还书处。图书馆工作人员扫描书籍的条形码，进行还书操作。如果借阅的书籍超期，则提示，并计算出应收罚款的数额。如果扫描失败，允许工作人员手工输入编号。

我采用了摘要方式来描述用例。我喜欢这样一种简洁的方式，它实际上等同于XP中的用户故事。在需求并不复杂的时候，或者在对文档要求并不严格的时候，都可以采用这种方式来编写用例。

以下是表达上述两个用例的用例图展现：

可以首先利用名词/动词法找到模型中的领域对象。这种方法虽然极度地简单与低级，然后在建立领域模型之初，是非常有效的手段。通过对用例的分析，大致可以获得如下对象：Reader，Administrator，Book，Library Card以及Scanner。也许还有我们未曾发现的领域对象，这可以通过深入领域或与客户交谈来进一步获得。我们可以尝试着先获得一个最简单的领域模型，如下所示。

我们发现Administrator对象是一个孤立的对象，它与其他领域对象没有产生任何关系。至少在借书、还书用例中，我们并不需要管理这个对象，可以考虑删除它。模型中的Scanner对象非常特殊，表面上它会对Book与LibraryCard进行操作，然而对于Scanner而言，它并不关心操作的是什么对象，而只需要扫描条形码，返回一个字符串。这是一种行为的体现。在整个系统中，Scanner对象可以只拥有一个，没有属性和状态，仅提供扫描功能，或者说是服务，因此可以考虑将其定义为服务对象。

Reader与Book之间的关系非常直接，可是在引入LibraryCard之后，这个关系就显得有些尴尬了。仔细阅读用例，我们发现识别读者的信息，是通过借书卡来获取的。无论是借书还是还书，都可以通过借书卡来获得读者当前借阅的书。此时，读者与书之间就不存在任何关系了，它已经进行了转嫁。既然借书卡已经实现了对借书关系的管理，我们还有必要保留Reader对象吗？阅读用例，我们知道在扫描借书卡时，会获得读者的信息。虽然我们可以在借书卡中保留这些信息，但根据单一职责原则（SRP），将其专门封装为一个对象仍有必要。

目前，借书卡仅仅维护了读者当前借阅的书籍，那么，还需要维护借阅和返还的历史记录吗？从用例的描述来看，并没有这一功能。我们感到疑惑，因为保留历史记录是大多数系统所必备的。此时，客户的答案就显得格外重要。“哦，是的，我们需要查看历史记录！”这是客户给我们的肯定答复。显然，查看历史记录属于另一个用例，它甚至可能属于另外一个上下文（Context），例如关于“查询”的上下文。然而，这一信息的来源却来自于借阅与返回用例，我们应该将其识别出来。如果其他用例需要用到，我认为这个对象是需要共享的。细化后的领域模型如下：

通过对扫描行为的分析，我认为Scanner提供的扫描行为与领域无关，而是一种基础设施，因此我将其定义为基础设施层的服务。模型增加了FineCalculator对象，用以完成对超期读者的罚款金额计算。显然，它是一个服务对象。注意，BorrowingHistory与Book是一对一的关系，因为我们需要为每一本书建立一条借阅历史记录。

现在，我们需要识别领域模型中的实体和值对象，以及可能的聚合。我们需要一个唯一的标识来区别读者，且这一标识具有连续性，因此Reader是一个实体对象。同样，Book对象也是一个实体对象，因为我们需要一个唯一标识来完成对书籍的跟踪。注意，在这个模型中的Book实体，其实例代表的是具体的某一本书，而不是指同一种书。因为图书馆可能就同一种书购买多本，而读者借阅的是真实的书本，而不仅仅是书的属性。此时，Book的标识ID就显得尤为重要，甚至不能用书籍的ISBN来标识。

从表面上看，BorrowingHistory同样属于实体对象，它的每一条记录都是唯一的，即使存在两条历史记录，具有相同的读者ID与书籍ID，我们仍将其视为不同的记录，因为它们的借阅时间并不相同。不过，对于系统的调用者而言，通常不会去关注所有的借阅记录，而是查询某位读者的借阅记录，因此，我们可以将其作为与Reader放在一起的聚合。然而，随着对需求的深入分析，我们发现定义这样的聚合存在问题，因为我们可能还需要查询某本书的借阅记录（例如，希望知道哪本书最受欢迎，跟踪每本书的借阅情况等）。由于Reader和Book应该分属于不同的聚合，BorrowingHistory就存在无法划定聚合的问题。既然如此，我们应该将其分离出来，作为一个单独的聚合根。

让人感觉疑惑不解的是LibraryCard对象。一方面，它的ID来源于Reader，且存在一对一的关系，因此它可以作为Reader聚合的一部分。根据模型图来看，它实际上又记录了读者与书之间的关系。仔细分析，LibraryCard所维护的这样一种读者与书的关系，事实上正是BorrowingHistory的一种体现，区别仅在于一个记录了当前的借书信息，一个还包括过去的借书信息。BorrowingHistory可以进行信息的持久化，LibraryCard则完全可以在内存中维持一个当前借阅信息的集合。因此，可以将LibraryCard定义在Reader聚合中。这样既可以减少对象之间的关联，又能保证对象之间的一致性。

我们还需要深入分析Reader对象和Book对象的标识ID，因为这两者的标识ID都是通过基础设施的Scanner服务获得的。Scanner并没有能力知道二者之间的区别。而在借阅书籍时，根据需求规定的流程，必须是先扫描借书卡，获得读者信息，然后再扫描书。此外，当扫描出现错误时，系统需要支持操作人员手工输入，因此对手工输入的内容也需要进行ID的验证。我们需要有专门验证ID的对象。

我们还要考虑许多业务规则，例如是否允许读者借书的规则，是否超期的规则，计算罚款额度的规则。如果这些规则极为简单，且不具有变化的可能，可以放在领域对象中。然而，一旦规则变得复杂，就会严重干扰相关领域对象的职责。根据职责分离的原则，我们可以提供专门的规则对象，即领域驱动设计中规格模式的应用。如果可能变化，我们甚至可以引入策略模式，对这些规则进行抽象。经过分析后得到的领域模型如下所示：

Reader实体对象和LibraryCard实体对象处于同一个聚合中，其中Reader为聚合根。BorrowingSpecification和ReturningSepecification均为值对象，并放在Reader聚合中。FineCalculator是一个服务对象，它会调用FineRule值对象获得罚款规则，通过计算后返回Money值对象值。由于聚合的原因，原来FineCalculator与LibraryCard之间的关系已经修改为计算Reader的罚款。

BorrowingHistory和Book均为实体对象，而IdentityValidator则为服务对象，负责验证扫描码。

接下来需要为领域对象选择资源库（Repository）。在领域模型中，只有Reader、BorrowingHistory和Book三个实体为聚合根对象，因此只需要为这三个对象建立资源库对象即可。

由于需求较为简单，建立的领域模型已经比较完善，我们可以着手编码，对这些模型进行验证。本文没有考虑限定上下文的情况，我希望未来的文章能够以真实的案例对此进行表述。整体而言，根据这个案例，我们已经能够初步领略领域驱动设计的基本步骤。

五月 12th, 2012 in Codelife, DDD | tags: | No Comments

领域驱动设计的分层

在引入实例以前，我们有必要回顾，并进一步了解分层架构。“层”是一种体系结构模式，也是被广大软件从业人员用得最为广泛而且最为灵活的模式之一。记得在CSDN上，时常有朋友问到：“分层是什么？为什么要分层？三层架构是不是就是表现层、业务逻辑层和数据访问层？”

到这里，你可能会觉得这些朋友的问题很简单，分层嘛，不就是将具有不同职责的组件分离开来，组成一套层内部高聚合，层与层之间低耦合的软件系统吗？不错！这是分层的目标。但是，我们应该如何分层呢？

领域驱动设计的讨论同样也是建立在层模式的基础上的，但与传统的分层架构相比，它更注重领域架构和技术架构的分离。

 

传统的三层架构

如上文那位朋友提的问题那样，最简单的分层方式自然就是“表现层、业务逻辑层和数据访问层”，我们可以用下图来表示这个思想：

注意图中打虚线的“基础结构层”，从实践的表现上来看，这部分内容可能就是一些帮助类，比如 SQLHelper之类的，也可能是一些工具类，比如TextUtility之类。这些东西可以被其它各层所访问。而基于分层的概念，表现层只能跟业务逻辑层打交道，而业务逻辑层在数据持久化方面的操作，则依赖于数据访问层。表现层对数据访问层的内容一无所知。

从领域驱动的角度看，这种分层的方式有一定的弊端。首先，为各个层面提供服务的“基础结构层”的职责比较紊乱，它可以是纯粹的技术框架，也可以包含或处理一定的业务逻辑，这样一来，业务逻辑层与“基础结构层”之间就会存在依赖关系；其次，这种结构过分地突出了“数据访问”的地位，把“数据访问”与 “业务逻辑”放在了等同的地位，这也难怪很多软件人员一上来就问：“我的数据表该如何设计？”

 

领域驱动设计的分层

领域驱动设计将软件系统分为四层：基础结构层、领域层、应用层和表现层。与上述的三层相比，数据访问层已经不在了，它被移到基础结构层了。

  • 基础结构层：该层专为其它各层提供技术框架支持。注意，这部分内容不会涉及任何业务知识。众所周知的数据访问的内容，也被放在了该层当中，因为数据的读写是业务无关的
  • 领域层：包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型（Domain Model）。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。有关领域对象和领域服务的内容，我会在接下来的案例中进行阐述
  • 应用层：该层不包含任何领域逻辑，但它会对任务进行协调，并可以维护应用程序的状态，因此，它更注重流程性的东西。在某些领域驱动设计的实践中，也会将其称为“工作流层”。应用层是领域驱动中最有争议的一个层次，也会有很多人对其职责感到模糊不清。比如，有些国外的开发人员会觉得，既然不包含领域逻辑，那又如何协调工作任务呢？我会在《应用层与实体事件》章节对这些问题进行探讨
  • 表现层：这个好理解，跟三层里的表现层意思差不多，但请注意，“Web服务”虽然是服务，但它是表现层的东西

从上图还可以看到，表现层与应用层之间是通过数据传输对象（DTO）进行交互的，数据传输对象是没有行为的POCO对象，它的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为何不能直接将领域对象用于数据传递？因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样做会直接将领域对象的行为暴露给表现层。

 

原文地址：

http://www.cnblogs.com/daxnet/archive/2010/07/07/1772584.html

 

四月 26th, 2012 in Codelife, DDD | tags: | No Comments

Interlocked

System.Threading.Interlocked类为多个线程共享的变量提供原子操作。

为整型类提供原子类操作

经验显示，那些需要在多线程情况下被保护的资源通常是整型值，且这些整型值在多线程下最常见的操作就是递增、递减或相加操作。Interlocked类提供了一个专门的机制用于完成这些特定的操作。这个类提供了Increment、Decrement、Add静态方法用于对int或long型变量的递增、递减或相加操作。


using System;
using System.Threading;

namespace ProcessTest
{
class Program
{
static int counter = 1;

static void Main(string[] args)
{
Thread t1 = new Thread(new ThreadStart(F1));
Thread t2 = new Thread(new ThreadStart(F2));

t1.Start();
t2.Start();

t1.Join();
t2.Join();

System.Console.ReadKey();
}

static void F1()
{
for (int i = 0; i < 5; i++)
{
Interlocked.Increment(ref counter);
System.Console.WriteLine(“Counter++ {0}”, counter);
Thread.Sleep(10);
}
}

static void F2()
{
for (int i = 0; i < 5; i++)
{
Interlocked.Decrement(ref counter);
System.Console.WriteLine(“Counter– {0}”, counter);
Thread.Sleep(10);
}
}
}
}

Interlocked类还提供了Exchange（为整型或引用对象赋值）、CompareExchange（比较后再对整型或引用对象赋值），用于为整型或引用类型的赋值提供原子操作。

其他参考：

http://msdn.microsoft.com/zh-cn/library/system.threading.interlocked.aspx

http://tech.ddvip.com/2009-09/1251897922130028.html

 

四月 25th, 2012 in Codelife | tags: | No Comments

以Windows身份验证方式登入Sql Server时，遇到登录拒绝错误18456的解决办法

当以Windows身份验证方式，登入Sql Server时，如果当前用户不是Sql Server内置的sysadmin角色用户，则登录将会被拒绝，如上图所示。

发生这种情况，一个可能的原因是在安装Sql Server时没有将当前用户添加到Sql Server管理员（即sysadmin角色）中。

解决方案如下：

1.以管理员身份运行SQL Server Management Studio

2.登录进入Sql Server之后，将需要的Windows用户添加到sysadmin角色中。

四月 10th, 2012 in Codelife, Sql | No Comments

事件驱动架构及应用

      Gartner在2003年引入了一个新术语事件驱动架构（Event Driven Architecture，EDA), 主要用于描述一种基于事件的范例。EDA 是一种用于进行设计和实现应用和系统的方法—在这些应用和系统里, 事件所触发的消息可以在独立的、非耦合的组件和服务之间传递，这些模块彼此并不知晓对方。这些应用程序中的EDA极大地改进了企业或政府响应不同的、表面上毫无关联事件的能力。通过提供瞬时过滤、聚合和关联事件的能力，EDA可以快速地检测出事件并判断它的类型，从而帮助组织机构快速、恰当地响应和处理这些事件。通常事件可以采用发布/订阅机制。

图1 SOA的请求应答模式

图2 EDA的事件驱动模式

    事件驱动架构概述

    一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward）。

    构建一个包含事件驱动构架的应用程序和系统，会使这些应用程序和系统响应更灵敏，因为事件驱动的系统更适合应用在不可预知的和异步的环境里。

    事件驱动架构在具体实现中是指由一系列相关组件构成的应用，而组件之间通过事件机制完成一定的业务功能。由于在一个EDA系统中各个组件都只专注于处理输入的消息与发布输出的消息，因而EDA系统能够更有加效地对管道化（pipelined）的、由多软件模块链接而成的并发事件流（concurrent processing of events）进行处理。

    EDA系统中各组件以异步方式响应事件，在本质上是可以并行的，因而在政府部门的电子政务应用中具有极大的优势。其具备以下特点:

    ◆ 并发执行

    ◆ 事件触发/数据触发/时间规则触发

    ◆ 实时/增量响应

    ◆ 分布式事件系统处理

    上述特点能很好地满足政府部门应用需求，如跨部门的应急联动系统或联合监管协同服务等应用。

    从目前情况来看，EDA系统还只是处理简单事件的系统，对于复杂事件的处理还有待进一步的研究。但是，EDA仍然能作为SOA系统的一个有效补充，弥补SOA系统的一些不足，如实时响应度不够。

    事件驱动架构优势

    事件驱动设计和开发所提供的优势如下所示:

    ◆ EDA提高了对不断变化的业务需求的响应，最大限度地减少了对现有业务应用的影响，也常消除了对新打包应用的需要。如果采用特有的粗颗粒服务模型可以基于业务目标快速确定可控的业务变更，并直接、迅速、有效地实施变更以达到业务敏捷性和完整性。

    ◆ 可以更容易开发和维护大规模分布式应用程序和不可预知的服务或异步服务;

    ◆ 可以很容易，低成本地集成、再集成、再配置新的和已存在的应用程序和服务。

    ◆ 促进远程组件和服务的再使用，拥有一个更灵敏、没有Bug的开发环境。

    从时间维度来看EDA的优势:

    ◆ 短期利益:更容易定制，因为设计对动态处理有更好的响应;

    ◆ 长期利益:系统和组织的状态变得更精准，对实时变化的响应接近于同步。

    EDA与SOA的关系

    SOA（service-oriented architecture）是面向服务的一种体系架构，1996年，Garnter就预见到了服务构架的重要性，并提出了SOA概念。有些观点认为EDA的出现会逐渐取代SOA，其实这并不正确，EDA并不会完全取代SOA，而会对SOA形成补充，有人称之为 "Event driven SOA"。虽然 SOA通常更适合请求/响应交换环境，但EDA 引入了一些长时间运行的异步进程功能。而且，EDA 节点可发布事件，且并不依赖于所发布的服务的可用性。它真正地实现了同其他节点的分离。

图3 EDA系统与SOA系统

   与Request/Response系统不同的是，要求请求者必须明确发送请求信息，而事件驱动架构提供一个机制去动态响应事件。在一个EDA系统里，事件产生者发布事件，事件消费者接受事件。

    业务系统可以从SOA和EDA中受益匪浅，因为事件发生时EDA系统能触发事件消费者，SOA服务可以快速地从相同的消费者中访问、查询。系统要求有最高的响应性，当事件被触发时这个系统必须能快速决定必须的动作。到事件结束，事件应该被发布和消费，而且事件要穿越SOA所有的边界，包括整个体系结构和物理层。

    系统要有最高的响应性，当事件触发时这个系统必须能快速决定必须的动作。到事件结束，事件应该被发布和消费，而且事件要穿越SOA所有的边界，包括整个体系结构和物理层。

ESB连接EDA和SOA

    企业服务总线(Enterprise Service Bus，ESB)在异类平台和环境间建立联系，充当允许不同应用程序进程之间进行通信的中间层。部署到企业服务总线的服务可以由使用者或事件触发。它同时支持同步方式和异步方式，可促进一个或多个参与者之间的交互。因此 ESB 可提供 SOA 和 EDA 范例的所有功能。“ESB提供了消息的传输，格式的转换等关键功能，为服务的请求者和服务提供者之间架设了沟通的桥梁，是企业应用基础架构的粘合剂。” 甲骨文公司大中华区高级技术经理黄建勇说。

    企业服务总线可连接各个异类节点并作为中介传递其间的所有通信和交互，这些节点可分散在面向服务的体系结构(同步一对一方法)和事件驱动的体系结构(异步多对多方法)中。ESB 是目前处理集成挑战的最有效方法，是可提供最大业务灵活性和不同应用程序间的高效连接技术解决方案。

    EDA应用在很多ESB（企业服务总线）产品中，比如FiornaoESB中间件产品支持同步、异步和请求响应事件，事件处理和传输实用不同的技术例如JMS，HTTP，电子邮件和基于XML的RPC等。比如“政府网上监察系统”通过对被监察对象（系统）数据的实时采集，通过EDA技术的事件触发，事件过滤，实现对违规、违法、越权行政、超时限行政等问题进行通知和督办等。

    EDA应用方向

    事件驱动架构(EDA)是分布式应用程序的普遍架构形式，非常典型的是:分布式应用程序都被设计成为模块化的、封装的、可共享事件服务的组件。能够通过应用程序、适配器以及无入侵性的代理操作来创建这些服务。由于EDA的特点，在金融贸易、能源贸易、电信以及欺诈检测这些行业中，一直都在采用事件驱动架构(EDA)技术。近期在我国政府的电子政务建设中，利用EDA分布式处理架构的优势构建共享交换平台，实现跨部门、跨平台、跨应用系统的政务信息资源的共享与交换，并对政府应急系统和跨委办局之间的业务协同办公提供支撑和保障。

PS：

ESB（Enterprise Service Bus）

基于EDA理念的企业消息通信层，用于减少对象之间的耦合度。对象（或系统）只需将事件（或消息）发送给ESB，由ESB选择下一步执行所需要的其他对象（或系统），以此重复解除发送者和接收者的关联性，实现Mediator Pattern。更多信息请参考：

http://zh.wikipedia.org/wiki/%E4%BC%81%E4%B8%9A%E6%9C%8D%E5%8A%A1%E6%80%BB%E7%BA%BF

http://baike.baidu.com/view/1224042.htm

 

原文：http://tech.it168.com/a2009/0313/268/000000268470.shtml

四月 1st, 2012 in General | tags: , , | No Comments

分布式数据系统库理论：CAP和BASE

CAP理论

在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素：

  • 一致性(Consistency)
  • 可用性(Availability)
  • 分区容忍性(Partition tolerance)

CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数web应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。

当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么无论系统可用性再、高分布式再好，也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则取决于数据复制到一致状态的时间。

最终一致性(eventually consistent)

对于一致性，可以分为从客户端和服务端两个不同的视角。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。

从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，又可以区分为：

  • 因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
  • “读己之所写（read-your-writes）”一致性。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
  • 会话（Session）一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
  • 单调（Monotonic）读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。
  • 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。

上述最终一致性的不同方式可以进行组合，例如单调读一致性和读己之所写一致性就可以组合实现。并且从实践的角度来看，这两者的组合，读取自己更新的数据，和一旦读取到最新的版本不会再读取旧版本，对于此架构上的程序开发来说，会少很多额外的烦恼。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。对于分布式数据系统：

  • N — 数据复制的份数
  • W — 更新数据是需要保证写完成的节点数
  • R — 读取数据的时候需要读取的节点数

如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读的是主库还是备库的数据，都是一致的。

如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。

对于分布式系统，为了保证高可用性，一般设置N>=3。不同的N,W,R组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。

  • 如果N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
  • 如果N=R,W=1，只需要一个节点写入成功即可，写性能和可用性都比较高。但是读取其他节点的进程可能不能获取更新后的数据，因此是弱一致性。这种情况下，如果W<(N+1)/2，并且写入的节点不重叠的话，则会存在写冲突

BASE理论

关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：

Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。

Consistency一致性. 在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。

Isolation隔离层. 两个事务的执行是互不干扰的，两个事务时间不会互相影响。

Durability持久性. 在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。

跨数据库事务：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，JavaEE中的JTA事务可以支持2PC。因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。

BASE理论模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：

Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)

Soft State软状态 状态可以有一段时间不同步，异步。

Eventually Consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

BASE思想的主要实现有

1.按功能划分数据库

2.sharding碎片

BASE思想主要强调基本的可用性，如果你需要High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

database-acid-vs-base

三月 26th, 2012 in Codelife, Data | tags: , | No Comments

两阶段提交

两阶段提交协议用于对运行在不同计算机上的两个或多个数据库的同步更新。这样可以确保事务要么全部成功，要么全部失败。因此，数据库作为整体而言，不存在不一致性状态。为了实现该功能，要指派一个中央协调员(数据库机器之一)，它可以协调提交/回滚操作的同步。两阶段提交协议中的其他参与者都有权认可是否现在提交。据此，中央协调员就事务提交还是回滚进行决策。对提交而言，中央协调员必须得到来自所有参与者的确认。即使只有一个参与者因为某种原因不能提交事务，也要回滚所有参与者的事务。其工作流程如下。

阶段1(准备阶段)

在这个阶段，中央协调员向事务的所有参与者发送准备提交的消息。作为响应，每个参与者向中央协调员要么发送准备提交的消息，要么发送不能提交的消息，这取决于它们提交事务后能否继续运行。

第一阶段

 

阶段2(提交阶段)

只有当中央协调员接收到来自所有参与者在第1阶段发送的准备提交消息时，它才会向所有参与者发送提交的消息。否则，它会向所有参与者发送事务回滚的消息。假定提交消息是由中央协调员发送的，所有参与者现在提交事务，并给协调员发送事务完成的消息。如果任何一个参与者因为某种原因在提交过程中出现故障，该参与者就会给中央协调员发回一条拒绝的消息。如果中央协调员收到至少一条拒绝消息，它就会要求所有参与者回滚；否则，就认为整个事务处理成功。

第二阶段

 

具体到分布式数据库的事务，两段提交协议也可以理解为：

  • 第一阶段，事务处理器（Windows下是MS DTC）向数据库服务器发出”准备提交”请求，数据库收到请求后执行相同的数据修改和日志记录等处理，不同的是处理完成后只是把事务的状态改成”可以提交”,然后把结果返回给事务处理器。
  • 事务处理器收到回应后进入第二阶段，如果在第一阶段内的危险期中发生了故障，事务处理器收不到回应，则认为事务失败，回撤事务。数据库服务器收不到第二阶段的确认提交请求，把”可以提交”的事务回撤.
  • 两阶段的第二阶段中事务处理器向数据库服务器发出”确认提交”请求，数据库服务器把事务的”可以提交”状态改为”提交完成”状态，然后返回应答。

从严格意义上说，两阶段提交并没有完全解决网络通讯危险期的问题，但因为第二阶段的处理很简单，只是修改了事务的状态，与第一阶段相比其处理时间极短，所以危险期极短，发生事务提交故障的可能性几乎不存在。 

 

.Net下分布式事务，请参考：

http://www.cnblogs.com/artech/archive/2010/01/31/1660433.html

三月 26th, 2012 in Codelife, Data | tags: , | No Comments

数据一致性

数据一致性通常指关联数据之间的逻辑关系是否正确和完整。而数据存储的一致性模型则可以认为是存储系统和数据使用者之间的一种约定。如果使用者遵循这种约定，则可以得到系统所承诺的访问结果。
常用的一致性模型有：
a、严格一致性（linearizability, strict/atomic Consistency）：读出的数据始终为最近写入的数据。这种一致性只有全局时钟存在时才有可能，在分布式网络环境不可能实现。

b、顺序一致性（sequential consistency）：所有使用者以同样的顺序看到对同一数据的操作，但是该顺序不一定是实时的。
c、因果一致性（causal consistency）：只有存在因果关系的写操作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证。因果一致性可以看做对顺序一致性性能的一种优化，但在实现时必须建立与维护因果依赖图，是相当困难的。
d、管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的进一步弱化，要求由某一个使用者完成的写操作可以被其他所有的使用者按照顺序的感知到，而从不同使用者中来的写操作则无需保证顺序，就像一个一个的管道一样。 相对来说比较容易实现。
e、弱一致性（weak consistency）：只要求对共享数据结构的访问保证顺序一致性。对于同步变量的操作具有顺序一致性，是全局可见的，且只有当没有写操作等待处理时才可进行，以保证对于临界区域的访问顺序进行。在同步时点，所有使用者可以看到相同的数据。
f、 释放一致性（release consistency）：弱一致性无法区分使用者是要进入临界区还是要出临界区， 释放一致性使用两个不同的操作语句进行了区分。需要写入时使用者acquire该对象，写完后release，acquire-release之间形成了一个临界区，提供 释放一致性也就意味着当release操作发生后，所有使用者应该可以看到该操作。
g、最终一致性（eventual consistency）：当没有新更新的情况下，更新最终会通过网络传播到所有副本点，所有副本点最终会一致，也就是说使用者在最终某个时间点前的中间过程中无法保证看到的是新写入的数据。可以采用最终一致性模型有一个关键要求：读出陈旧数据是可以接受的。
h、delta consistency：系统会在delta时间内达到一致。这段时间内会存在一个不一致的窗口，该窗口可能是因为log shipping的过程导致。

最终一致性的几种具体实现：
1、读不旧于写一致性（Read-your-writes consistency）：使用者读到的数据，总是不旧于自身上一个写入的数据。
2、会话一致性（Session consistency）：比读不旧于写一致性更弱化。使用者在一个会话中才保证读写一致性，启动新会话后则无需保证。
3、单读一致性（Monotonic read consistency）：读到的数据总是不旧于上一次读到的数据。
4、单写一致性（Monotonic write consistency）：写入的数据完成后才能开始下一次的写入。
5、写不旧于读一致性（Writes-follow-reads consistency）：写入的副本不旧于上一次读到的数据，即不会写入更旧的数据。

Werner Vogels认为：在很多互联网应用中，单读一致性＋读不旧于写一致性可以提供足够的一致性了。

三月 24th, 2012 in Codelife, Data | tags: | No Comments
←Older