文章转自：
 
http://deadhorse.me/nodejs/2013/04/13/exception_and_domain.html
 
https://cnodejs.org/topic/516b64596d38277306407936
 
 
http://blog.fens.me/nodejs-core-domain/
 
 
 
 
 
 
 
domain的API介绍
 
 
基本概念
 
 
隐式绑定: 把在domain上下文中定义的变量，自动绑定到domain对象
显式绑定: 把不是在domain上下文中定义的变量，以代码的方式绑定到domain对象
 
 
API介绍
 
 
domain.create(): 返回一个domain对象
domain.run(fn): 在domain上下文中执行一个函数，并隐式绑定所有事件，定时器和低级的请求。
domain.members: 已加入domain对象的域定时器和事件发射器的数组。
domain.add(emitter): 显式的增加事件
domain.remove(emitter): 删除事件
domain.bind(callback): 以return为封装callback函数
domain.intercept(callback): 同domain.bind，但只返回第一个参数
domain.enter(): 进入一个异步调用的上下文，绑定到domain
domain.exit(): 退出当前的domain，切换到不同的链的异步调用的上下文中。对应domain.enter()
domain.dispose(): 释放一个domain对象，让node进程回收这部分资源
  
 
异步异常处理
 
 
异步异常的特点
 
 
由于node的回调异步特性，无法通过try catch来捕捉所有的异常： 
 
 
 
  
try {
  process.nextTick(function () {
    foo.bar();
  });
} catch (err) {
  //can not catch it
}
 
 
 
 
而对于web服务而言，其实是非常希望这样的： 
 
 
 
  
//express风格的路由
app.get('/index', function (req, res) {
  try {
    //业务逻辑
  } catch (err) {
    logger.error(err);
    res.statusCode = 500;
    return res.json({success: false, message: '服务器异常'});
  }
});
 
 
 
 
如果try catch能够捕获所有的异常，这样我们可以在代码出现一些非预期的错误时，能够记录下错误的同时，友好的给调用者返回一个500错误。可惜，try catch无法捕获异步中的异常。所以我们能做的只能是：
 
 
 
  
app.get('/index', function (req, res) {
  // 业务逻辑  
});

process.on('uncaughtException', function (err) {
  logger.error(err);
});
 
 
 
 
这个时候，虽然我们可以记录下这个错误的日志，且进程也不会异常退出，但是我们是没有办法对发现错误的请求友好返回的，只能够让它超时返回。 
 
 
domain
 
 
在node v0.8+版本的时候，发布了一个模块domain。这个模块做的就是try catch所无法做到的：捕捉异步回调中出现的异常。
 于是乎，我们上面那个无奈的例子好像有了解决的方案： 
 
 
 
  
var domain = require('domain');

//引入一个domain的中间件，将每一个请求都包裹在一个独立的domain中
//domain来处理异常
app.use(function (req,res, next) {
  var d = domain.create();
  //监听domain的错误事件
  d.on('error', function (err) {
    logger.error(err);
    res.statusCode = 500;
    res.json({sucess:false, messag: '服务器异常'});
    d.dispose();
  });

  d.add(req);
  d.add(res);
  d.run(next);
});

app.get('/index', function (req, res) {
  //处理业务
});
 
 
 
 
我们通过中间件的形式，引入domain来处理异步中的异常。当然，domain虽然捕捉到了异常，但是还是由于异常而导致的堆栈丢失会导致内存泄漏，所以出现这种情况的时候还是需要重启这个进程的，有兴趣的同学可以去看看domain-middleware这个domain中间件。
 
 
诡异的失效
 
 
我们的测试一切正常，当正式在生产环境中使用的时候，发现domain突然失效了！它竟然没有捕获到异步中的异常，最终导致进程异常退出。经过一番排查，最后发现是由于引入了redis来存放session导致的。
 
 
 
  
var http = require('http');
var connect = require('connect');
var RedisStore = require('connect-redis')(connect);
var domainMiddleware = require('domain-middleware');

var server = http.createServer();
var app = connect();
app.use(connect.session({
  key: 'key',
  secret: 'secret',
  store: new RedisStore(6379, 'localhost')
}));
//domainMiddleware的使用可以看前面的链接
app.use(domainMiddleware({
  server: server,
  killTimeout: 30000
}));
 
 
 
 
此时，当我们的业务逻辑代码中出现了异常，发现竟然没有被domain捕获！经过一番尝试，终于将问题定位到了： 
 
 
 
  
var domain = require('domain');
var redis = require('redis');
var cache = redis.createClient(6379, 'localhost');

function error() {
  cache.get('a', function () {
    throw new Error('something wrong');
  });
}

function ok () {
  setTimeout(function () {
    throw new Error('something wrong');
  }, 100);
}
var d = domain.create();
d.on('error', function (err) {
  console.log(err);
});

d.run(ok);    //domain捕获到异常
d.run(error); //异常被抛出
 
 
 
 
奇怪了！都是异步调用，为什么前者被捕获，后者却没办法捕获到呢？ 
 
 
Domain剖析
 
 
回过头来，我们来看看domain做了些什么来让我们捕获异步的请求(代码来自node v0.10.4，此部分可能正在快速变更优化)。如果对domain还不甚了解的同学可以先简单过一下domain的文档。
 
 
node事件循环机制
 
 
在看Domain的原理之前，我们先要了解一下nextTick和_tickCallback的两个方法。
 
 
 
  
function laterCallback() {
  console.log('print me later');
}

process.nextTick(laterCallback);
console.log('print me first');
 
 
 
 
上面这段代码写过node的人都很熟悉，nextTick的作用就是把laterCallback放到下一个事件循环去执行。而_tickCallback方法则是一个非公开的方法，这个方法是在当前时间循环结束之后，调用之以继续进行下一个事件循环的入口函数。
 
 
换而言之，node为事件循环维持了一个队列，nextTick入队，_tickCallback出列。 
 
 
domain的实现
 
 
在了解了node的事件循环机制之后，我们再来看看domain做了些什么。
 domain自身其实是一个EventEmitter对象，它通过事件的方式来传递捕获的错误。这样我们在研究它的时候，就简化到两个点： 
 
 
 
什么时候触发domain的error事件： 
 
   
进程抛出了异常，没有被任何的try catch捕获到，这时候将会触发整个process的processFatal，此时如果在domain包裹之中，将会在domain上触发error事件，反之，将会在process上触发uncaughtException事件。
 
 
 
domain如何在多个不同的事件循环中传递： 
 
   
当domain被实例化之后，我们通常会调用它的run方法（如之前在web服务中的使用），来将某个函数在这个domain示例的包裹中执行。被包裹的函数在执行的时候，process.domain这个全局变量将会被指向这个domain实例。当这个事件循环中，抛出异常调用processFatal的时候，发现process.domain存在，就会在domain上触发error事件。
 
在require引入domain模块之后，会重写全局的nextTick和_tickCallback,注入一些domain相关的代码：
 
   
 
    
//简化后的domain传递部分代码
function nextDomainTick(callback) {
  nextTickQueue.push({callback: callback, domain: process.domain});
}

function _tickDomainCallback() {
  var tock = nextTickQueue.pop();
  //设置process.domain = tock.domain
  tock.domain && tock.domain.enter();
  callback();
  //清除process.domain
  tock.domain && tock.domain.exit();        
  }
};
 
   
 
 
 
这个是其在多个事件循环中传递domain的关键：nextTick入队的时候，记录下当前的domain，当这个被加入队列中的事件循环被_tickCallback启动执行的时候，将新的事件循环的process.domain置为之前记录的domain。这样，在被domain所包裹的代码中，不管如何调用process.nextTick, domain将会一直被传递下去。
 3. 当然，node的异步还有两种情况，一种是event形式。因此在EventEmitter的构造函数有如下代码：
 
 
 
  
    if (exports.usingDomains) {
      // if there is an active domain, then attach to it.
      domain = domain || require('domain');
      if (domain.active && !(this instanceof domain.Domain)) {
        this.domain = domain.active;
      }
    }
 
 
 
 
实例化EventEmitter的时候，将会把这个对象和当前的domain绑定，当通过emit触发这个对象上的事件时，像_tickCallback执行的时候一样，回调函数将会重新被当前的domain包裹住。
 4. 而另一种情况，是setTimeout和setInterval，同样的，在timer的源码中，我们也可以发现这样的一句代码:
 
 
 
  
   if (process.domain) timer.domain = process.domain;
 
 
 
 
跟EventEmmiter一样，之后这些timer的回调函数也将被当前的domain包裹住了。 
 
 
node通过在nextTick, timer, event三个关键的地方插入domain的代码，让它们得以在不同的事件循环中传递。
 
 
更复杂的domain
 
 
有些情况下，我们可能会遇到需要更加复杂的domain使用。 
 
 
domain嵌套：我们可能会外层有domain的情况下，内层还有其他的domain，使用情景可以在文档中找到
 
 
 
 
  
// create a top-level domain for the server
var serverDomain = domain.create();

serverDomain.run(function() {
  // server is created in the scope of serverDomain
  http.createServer(function(req, res) {
    // req and res are also created in the scope of serverDomain
    // however, we'd prefer to have a separate domain for each request.
    // create it first thing, and add req and res to it.
    var reqd = domain.create();
    reqd.add(req);
    reqd.add(res);
    reqd.on('error', function(er) {
      console.error('Error', er, req.url);
      try {
        res.writeHead(500);
        res.end('Error occurred, sorry.');
      } catch (er) {
        console.error('Error sending 500', er, req.url);
      }
    });
  }).listen(1337);
});
 
 
 
 
为了实现这个功能，其实domain还会偷偷的自己维持一个domain的stack，有兴趣的童鞋可以在这里看到。
 
 
回头解决疑惑
 
 
回过头来，我们再来看刚才遇到的问题：为什么两个看上去都是同样的异步调用，却有一个domain无法捕获到异常？理解了原理之后不难想到，肯定是调用了redis的那个异步调用在抛出错误的这个事件循环内，是不在domain的范围之内的。我们通过一段更加简短的代码来看看，到底在哪里出的问题。
 
 
 
  
var domain = require('domain');
var EventEmitter = require('events').EventEmitter;

var e = new EventEmitter();

var timer = setTimeout(function () {
  e.emit('data');  
}, 10);

function next() {
  e.once('data', function () {
    throw new Error('something wrong here');
  });
}

var d = domain.create();
d.on('error', function () {
  console.log('cache by domain');
});

d.run(next);
 
 
 
 
此时我们同样发现，错误不会被domain捕捉到，原因很清晰了：timer和e两个关键的对象在初始化的时候都时没有在domain的范围之内，因此，当在next函数中监听的事件被触发，执行抛出异常的回调函数时，其实根本就没有处于domain的包裹中，当然就不会被domain捕获到异常了！
 
 
其实node针对这种情况，专门设计了一个API：domain.add。它可以将domain之外的timer和event对象，添加到当前domain中去。对于上面那个例子：
 
 
 
  
d.add(timer);
//or
d.add(e);
 
 
 
 
将timer或者e任意一个对象添加到domain上，就可以让错误被domain捕获了。 
 
 
再来看最开始redis导致domain无法捕捉到异常的问题。我们是不是也有办法可以解决呢？
 看@python发烧友 的这条微博我们就能理解，其实对于这种情况，还是没有办法实现最佳的解决方案的。现在对于非预期的异常产生的时候，我们只能够让当前请求超时，然后让这个进程停止服务，之后重新启动。graceful模块配合cluster就可以实现这个解决方案。
 
 
domain十分强大，但不是万能的。希望在看过这篇文章之后，大家能够正确的使用domian，避免踩坑。:)
 
 
 
 
题外推荐
 
 
在整个问题排查与代码研究过程中，有一个工具起了巨大的作用：node-inspector，它可以让node代码在chrome下进行单步调试，能够跟进到node源码之中，@goddyzhao的文章使用node-inspector来调试node详细介绍了如何使用node-inspector。
 
 

 

欢迎大家光临我的个人博客，详戳    https://545longgege.top/
 
最近在改一个bug单时，有个问题涉及到了cookie的domain属性，大致场景是由于不同的服务页面出现了同名的cookie但是domain域不同，导致出现了不可思议的bug。于是查询与cookie的domain属性相关的资料并记录之。
 
1、什么是Cookie?
 
    Cookie是由W3C组织提出，最早由NetScape社区发展的一种机制。
 
    Cookie是存储于访问者的计算机中的变量。每当同一台计算机通过浏览器请求某个页面时，就会发送这个cookie。
 
    Cookie的作用就是用于解决"如何记录客户端的用户信息"：
 
        ①当用户访问web页面时，他的名字可以记录在Cookie中。
 
        ②在用户下一次访问该页面时，可以在Cookie中读取用户访问记录。
 
    Cookie实际上是一小段文本信息（上限为4kb）。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器可以把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务还可以根据需要修改Cookie的内容。
 
2、Cookie的属性
 
属性名
描述
name
Cookie的名称，Cookie一旦创建，名称便不可更改
value
Cookie的值，如果值为Unicode字符，需要为字符编码。如果为二进制数据，则需要使用BASE64编码
maxAge
Cookie失效的时间，单位秒。如果为整数，则该Cookie在maxAge秒后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为-1。
secure
该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。
path
Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。
domain
可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”。
comment
该Cookie的用处说明，浏览器显示Cookie信息的时候显示该说明。
version
Cookie使用的版本号。0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范
例如：
 
document.cookie = "username=Darren;path=/;domain=.csdn.net"
 
将上面代码复制在console控制台中输入，回车便可以在浏览器的cookie中查到username被存在Domain为'".csdn.net'的域名下。
 
 
3、Cookie的Domain属性
 
    我们重点说一下这个Domain属性。一般在实现单点登录的时候会经常用到这个属性，通过在父级域设置Cookie，然后在各个子级域拿到存在父级域中的Cookie值。比如刚才设置的username属性，在blog.csdn.net下同样可以访问到，用户不用重新登录就可以拿到第一次登录进来时候的用户信息，因为这些用户信息都是存在父级域".csdn.net"下面，其他页面也可以拿到。
 
 
 
所谓的单点登录是指用户在一个站点如www.studyez.com登录后切换到另一个站点communty.studyez.com时也自动 被community的Server判断为已经登录，反过来，只要用户在community.studyez.com登出后，切换到 www.studyez.com时后www的Server也会判断到这一用户已经登出。
 
 
 因此，当在"blog.csdn.net"这个域名下存入一个Cookie;如：
 
document.cookie = "blogCookie=blog;path=/;domain=.blog.csdn.net";
 
然后你会发现在mp.csdn.net下看不到blogCookie这个属性。这个就是所谓的Cookie跨域的问题。 
 
 
 
补充说明：
 
 
设置domain的值，前面带点和不带点的区别：
 
 
1. 带点：任何subdomain都可以访问，包括父domain
 
 
2. 不带点：只有完全一样的域名才能访问，subdomain不能访问(但在IE下比较特殊，它支持subdomain访问)
 
 
 
 
总结：domain表示的是cookie所在的域，默认为请求的地址，如网址为www.study.com/study，那么domain默认为www.study.com。而跨域访问，如域A为t1.study.com，域B为t2.study.com，那么在域A生产一个令域A和域B都能访问的cookie就要将该cookie的domain设置为.study.com；如果要在域A生产一个令域A不能访问而域B能访问的cookie就要将该cookie的domain设置为t2.study.com。注意：一般在域名前是需要加一个"."的，如"domain=.study.com"。
 
 
 

推荐：博主历时三年倾注大量心血创作的《大数据平台架构与原型实现：数据中台建设实战》一书已由知名IT图书品牌电子工业出版社博文视点出版发行，真诚推荐给每一位读者！点击《重磅推荐：建大数据平台太难了！给我发个工程原型吧！》了解图书详情，扫码进入京东手机购书页面！
 
 
 
 
领域驱动设计(Domain Driven Design)参考架构详解
 
摘要
 
本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构，该架构分成了Interfaces、Applications和Domain三层以及包含各类基础设施的Infrastructure。本文会对架构中一些重要组件和问题进行讨论，给出一些分析结论。本文原文连接：http://blog.csdn.net/bluishglc/article/details/6681253 转载请注明出处！
 
目录
 

 1.      架构概述
 2.      架构详解
         2.1.       Interfaces-接口层
                 2.1.1.        DTO
                 2.1.2.        Assembler
                 2.1.3.        Facade
         2.2.       Application-应用层
         2.3.       Domain-领域层
         2.4.       Infrastructure-基础设施层
 3.      关于架构的一些讨论
         3.1.       架构并不能保证领域驱动设计的贯彻与执行
         3.2.       Fa?ade是否是必须的？
 
1.      架构概述
 
 
 
领域驱动设计(Domain Driven Design)有一个官方的sample工程，名为DDDSample,官网：http://dddsample.sourceforge.net/，该工程给出了一种实践领域驱动设计的参考架构，本文将对此该架构进行简单介绍，并就一些重要问题进行讨论。
 
该架构分成了Interfaces、Applications和Domain三层以及包含各类基础设施的Infrastructure。下图简略描述了它们之间的关系：
 
 
图1：领域驱动设计风格的架构草图(来自于DDDSample官网）
 
下图是详细架构：
 
 
图2：领域驱动设计参考架构
 
作为参照，下图展示了传统TransactionScript风格的架构，可以看出，两者的差异并不是太大（对于Façade来说，它是一种可选设施，如果系统架构中省略Façade，则DTO与领域对象的互换工作可在service中进行），这也从则面说明推行领域驱动设计的关键并不在架构上，而在于整个团队在分析、设计和开发上没有自始至终地以领域模型为核心开展工作，以面向对象的思想进行设计和编程。
 
Transaction Script风格的架构具有明显的“数据”与“操作”分离的特征，其和领域驱动设计风格的架构在两个类组件上有质的区别，一个是领域对象，一个是Service。领域驱动设计的架构核心目标是要创建一个富领域模型，其典型特征是它的领域对象具有丰富的业务方法用以处理业务逻辑，而Transaction Script风格的领域对象则仅仅是数据的载体，没有业务方法，这种领域也被称作“贫血的领域对象”(Anemic Domain Objects)。在Service方面，领域驱动设计的架构里Service是非常“薄“的一层，其并不负责处理业务逻辑，而在TransactionScript风格的架构里，Service是处理业务逻辑的主要场所，因而往往非常厚重。
 
 
图3：数据与操作分离的Transaction Script风格的架构
 
2.      架构详解
 
2.1.    Interfaces-接口层
 
领域驱动设计对Interfaces的定位是:
 
Thislayer holds everything that interacts with other systems, such as web services,RMI interfaces or web applications, and batch processing frontends. It handlesinterpretation, validation and translation of incoming data. It also handlesserialization of outgoing data, such as HTML or XML across HTTP to web browsersor web service clients, or DTO classes and distributed facade interfaces forremote Java clients.
 
该层包含与其他系统进行交互的接口与通信设施，在多数应用里，该层可能提供包括Web Services、RMI或Rest等在内的一种或多种通信接口。该层主要由Façade、DTO和Assembler三类组件构成，三类组件均是典型的J2EE模式，以下是对三类组件的具体介绍：
 
2.1.1.   DTO
 
DTO- DataTransfer Object（数据传输对象），也常被称作VO-Value Object(值对象)。基于面向对象技术设计的领域对象（即通常所说的“实体”）都是细粒度的，将细粒度的领域对象直接传递到远程调用端需要进行多次网络通信，DTO在设计之初的主要考量是以粗粒度的数据结构减少网络通信并简化调用接口。以下罗列了DTO的多项作用：
 
 
 
        Reduces network traffic
 
        Simplifies remote object and remote interface
 
        Transfers more data in fewer remote calls
 
        Reduces code duplication
 
        Introduces stale transfer objects
 
        Increases complexity due to synchronization and version control
 
 
图4.DTO应用时序图(基于《Core J2EE Patterns》插图进行了修改）
 
值得一提的是，DTO对实现一个独立封闭的领域模型具有积极的作用，特别是当系统使用了某些具有自动脏数据检查（automatic dirty checking）机制的ORM框架时，DTO的优势就更加明显，否则就会存在领域对象在模型层以外被意外修改并自动持久化到数据库中的风险或者是像Hibernate那样的框架因未开启OpenSessionInView (注：开启OpenSessionInView有副作用，一般认为OpenSessionInView不是一种好的实践)而导致Lazy Loading出现问题。
 
关于DTO具体的设计用意和应用场景可参考如下资源：
 
1.《Core J2EE™ Patterns: Best Practices and Design Strategies, SecondEdition》
 
2.《Patterns of Enterprise ApplicationArchitecture》
 
2.1.2.   Assembler
 
在引入DTO后，DTO与领域对象之间的相互转换工作多由Assembler承担，因此Assembler几乎总是同DTO一起出现。也有一些系统使用反射机制自动实现DTO与领域对象之间的相互转换，Appache的Commons BeanUtils就提供了类似的功能。应该说这两种实现各有利弊，使用Assembler进行对象数据交换更为安全与可控，并且接受编译期检查，但是代码量明显偏多。使用反射机制自动进行象数据交换虽然代码量很少，但却是非常脆弱的，一旦对象属性名发生了变化，数据交互就会失败，并且很难追踪发现。总体来说，Assembler更为直白和稳妥。
 
 
图5.Assebler应用类图(基于《Core J2EE Patterns》插图进行了修改）
 
关于Assembler具体的设计用意和应用场景可参考如下资源：
 
1.《Core J2EE™ Patterns: Best Practices and Design Strategies, SecondEdition》
 
2.《Patterns of Enterprise ApplicationArchitecture》
 
2.1.3.   Facade
 
作为一种设计模式同时也是Interfaces层内的一类组件，Façade的用意在于为远程客户端提供粗粒度的调用接口。Façade本身不处理任何的业务逻辑，它的主要工作就是将一个用户请求委派给一个或多个Service进行处理，同时借助Assembler将Service传入或传出的领域对象转化为DTO进行传输。以下罗列了Façade的多项作用：
 
 
 
 
 
 
Introduces a layer that provides services to remote clients
 
Exposes a uniform coarse-grained interface
 
Reduces coupling between the tiers
 
Promotes layering, increases flexibility and maintainability
 
Reduces complexity
 
Improves performance, reduces fine-grained remote methods
 
Centralizes security management
 
Centralizes transaction control
 
Exposes fewer remote interfaces to clients
 
 
 
实践Façade的过程中最难把握的问题就是Façade的粒度问题。传统的Service均以实体为单位进行组织，而Façade应该具有更粗粒度的组织依据，较为合适的粒度依据有：一个高度内聚的模块一个Façade,或者是一个“聚合”(特指领域驱动设计中的聚合)一个Façade.
 
 
图6.Façade应用类图(基于《Core J2EE Patterns》插图进行了修改）
 
 
图7.Façade应用时序图(基于《Core J2EE Patterns》插图进行了修改）
 
关于Assembler具体的设计用意和应用场景可参考如下资源：
 
1.《Core J2EE™ Patterns: Best Practices and Design Strategies, SecondEdition》
 
2.《Patterns of Enterprise ApplicationArchitecture》
 
3.《Design Patterns: Elementsof Reusable Object-Oriented Software》
 
2.2.    Application-应用层
 
领域驱动设计对Application的定位是:
 
Theapplication layer is responsible for driving the workflow of the application,matching the use cases at hand. These operations are interface-independent andcan be both synchronous or message-driven. This layer is well suited forspanning transactions, high-level logging and security. The application layeris thin in terms of domain logic - it merely coordinates the domain layerobjects to perform the actual work.
 
Application层中主要组件就是Service,在领域驱动设计的架构里，Service的组织粒度和接口设计依据与传统Transaction Script风格的Service是一致的，但是两者的实现却有着质的区别。TransactionScript风格的Service是实现业务逻辑的主要场所，因此往往非常厚重。而在领域驱动设计的架构里，Application是非常“薄”的一层，所有的Service只负责协调并委派业务逻辑给领域对象进行处理，其本身并真正实现业务逻辑，绝大部分的业务逻辑都由领域对象承载和实现了，这是区别系统是Transaction Script架构还是Domain Model架构的重要标志。
 
不管是Transaction Script风格还Domain Model风格，Service都会与多种组件进行交互，这些组件包括：其他的Service、领域对象和Repository 或 DAO。
 
 
图8. Service应用时序图(基于《Core J2EE Patterns》插图进行了修改）
 
 
 
Service的接口是面向用例设计的，是控制事务、安全的适宜场所。如果Façade的某一方法需要调用两个以上的Service方法，需要注意事务问题。
 
 
 
2.3.    Domain-领域层
 
 
 
领域驱动设计对Domain的定位是:
 
Thedomain layer is the heart of the software, and this is where the interestingstuff happens. There is one package per aggregate, and to each aggregatebelongs entities, value objects, domain events, a repository interface andsometimes factories.
 
Thecore of the business logic belongs in here. The structure and naming ofaggregates, classes and methods in the domain layer should follow theubiquitous language, and you should be able to explain to a domain expert howthis part of the software works by drawing a few simple diagrams and using theactual class and method names of the source code.
 
Domain层是整个系统的核心层，该层维护一个使用面向对象技术实现的领域模型，几乎全部的业务逻辑会在该层实现。Domain层包含Entity（实体）、ValueObject(值对象)、Domain Event（领域事件）和Repository（仓储）等多种重要的领域组件。
 
2.4.    Infrastructure-基础设施层
 
领域驱动设计对Infrastructure的定位是:
 
Inaddition to the three vertical layers, there is also the infrastructure. As thethe picture shows, it supports all of the three layers in different ways,facilitating communication between the layers. In simple terms, theinfrastructure consists of everything that exists independently of ourapplication: external libraries, database engine, application server, messagingbackend and so on.
 
Also,we consider code and configuration files that glues the other layers to theinfrastructure as part of the infrastructure layer. Looking for example at thepersistence aspect, the database schema definition, Hibernate configuration andmapping files and implementations of the repository interfaces are part of theinfrastructure layer.
 
Whileit can be tricky to give a solid definition of what kind of code belongs to theinfrastructure layer for any given situation, it should be possible tocompletely stub out the infrastructure in pure Java unit/scenario tests andstill be able to use the domain layer and possibly the application layer towork out the core business problems.
 
作为基础设施层，Infrastructure为Interfaces、Application和Domain三层提供支撑。所有与具体平台、框架相关的实现会在Infrastructure中提供，避免三层特别是Domain层掺杂进这些实现，从而“污染”领域模型。Infrastructure中最常见的一类设施是对象持久化的具体实现。
 
 
 
3.      关于架构的一些讨论    
 
3.1.    架构并不能保证领域驱动设计的贯彻与执行
 
 
 
虽然一个合适的架构对于实施领域驱动设计是大有必要的，但只依靠架构是不能保证领域驱动设计的贯彻与执行的。实际上，在这个参考架构上使用Transaction Script的方式进行开法几乎没有任何问题，只要开发人员将领域对象变成“贫血”的“数据载体”对待，在service里实现业务逻辑，那么该参考架构将成为纯粹的TransactionScript方式。当然反过来看，这也体现了这一架构的灵活性。确保领域驱动设计的贯彻与执行需要整个团队在分析、设计和开发上没有自始至终地以领域模型为核心开展工作，以面向对象的思想进行设计和编程，才能保证实现领域驱动设计。
 
3.2.    Façade是否是必须的？
 
尽管在架构中对Façade的定义非常清晰，但在实践中我发现Façade并不是一个容易拿捏的东西。主要问题在于其与service之间的有太多的重叠与相似之处。我们注意到service是接口是面向一个use case的，因此事务也是追加在service这一层上，于是对于façade而言，99%的情况是，它只是把某个service的某个方法再包裹一下而已，如果把领域对象和DTO的互转换工作移至service中进行，那么façade将彻底变成空壳，而关键的是：如果service的接口设计是面向和user case的，那么，毫无疑问，service接口的传入传出参数也都应该是DTO，而这一点也在《Core J2EE™ Patterns: Best Practices and Design Strategies, SecondEdition》和《Patterns of Enterprise ApplicationArchitecture》两书的示例代码中完全印证了。那么，从更为务实角度出发，Façade并非是一种必须的组件。

domain的概念，通常会分很多层，比如经典的三层架构，控制层、业务层、数据访问层（DAO），此外，还有一个层，就是domain层
domain层，通常就是用于放置这个系统中，与数据库中的表，一一对应起来的JavaBean的


model层：和domain区别；可能都是javaBean，
这个区别是用途不同，domain通常就代表了与数据库表--一一对应的javaBean,
model通常代表了不与数据库一一对应的javaBean，但是封装的数据是前端的JS脚本，需要使用的数据