三层架构，够不够---DDD眼中的三层（附C#源代码实现）

软件复杂度的根本，来源于思维的复杂度。

三层架构

从DDD看三层

DDD的三层实现详细架构

看代码

业务域 （Domain）

持久层 （数据层）

测试和使用的例子

完整代码下载

 

---

 

 得心应手武器库:

• Fluent nHibernate

• nUnit

• Git （GitHub)
  

 本文所涉及使用的工具, 见前文: 我的.Net武器库 ------ 新.Net架构必备工具列表

三层架构

相对于目前日新月异的新概念，新名词，三层架构已经算得上元老了。虽仍有争议，但业界更多的是共识。

图1 常用三层的描述图

 

足够简单、清晰，我仍要提醒的是，注意层之间连线的箭头，非常之重要，借用UML的定义，箭头表示依赖关系。也就是说，必须先有数据层，才有业务层，然后才有表现层。这又怎么样，小问题。不，这是一个大麻烦！

从DDD看三层

我们暂时靶这个话题放一放，挑个比较新一点的东西。业务域驱动开发(DDD) 近年也是风生水起，红红火火，但它是什么，是怎么回事，似乎就不如三层架构那么妇孺皆知了。

图2 从DDD的角度看三层架构

 

以业务域为系统的核心，所有其它与业务无关的内容对这个核心来谈，都是外部服务/功能。这里，出于本文说明的需要，独立出了两个较为特别的外部功能，持久层和用户接口。

两个看上去完全不同的架构设计，哪个更对哪个更好?每一个都有大量的拥护者，大量的讨论，互相三间似乎又泾渭分明，至少我们经常看到的文章给我们如此的印象。自然，我们的思考，为什么不能融合在一起呢？其实，它们并不像看起来区别那么大。从名词上，虽然我有意把名称错开，我们也仍能看到之间的对应关系、业务层=业务域，数据层=持久层，表现层=用户接口。当然，这些细节用词的不同仍有必要的，毕竟，它们不完全是一回事。

DDD的三层实现详细架构

好了，抽象的讨论已经足够了，我们也足够糊涂了。细节为王，我们如何实现？来看看这个实际系统的简化架构图。.