当今的企业应用程序无疑是复杂的，并且依靠某些专门技术（持久性，AJAX，Web服务等）来完成其工作。作为开发人员，我们倾向于专注于这些技术细节是可以理解的。但是事实是，不能解决业务需求的系统对任何人都没有用，无论它的外观多么漂亮或其基础架构的架构如何。
领域驱动设计（“Domain-Driven Design领域驱动设计”简称DDD）的哲学-由埃里克·埃文斯（Eric Evans）在他的同名书中首次描述-旨在将我们的注意力放在应用程序的核心，专注于业务领域固有的复杂性本身。我们还将核心域（对业务而言是唯一的）与支持子域（本质上通常是通用的，例如金钱或时间）区分开来，并将更多的设计工作适当地放在核心上。
过去系统分析和系统设计都是分离的，正如我们国家“系统分析师” 和“系统设计师” 两种职称考试一样，这样割裂的结果导致，需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。DDD包括一组用于从域模型构建企业应用程序的模式。
代码和模型...
借助DDD，我们正在寻求创建问题域的模型。持久性，用户界面和消息传递内容可能会在以后出现，这是需要了解的领域，因为这是所构建系统中将您公司的业务与竞争对手区分开来的部分。 （如果事实并非如此，则可以考虑购买包装产品）。
通过模型，我们不是指一个图或一组图。当然，图是有用的，但它们不是模型，只是模型的不同视图（参见图）。
模型与模型视图
所以模型是我们选择在软件中实现的概念集，以代码和用于构建交付系统的任何其他软件工件表示。换句话说，代码本身就是模型。文本编辑器提供了使用此模型的一种方法，尽管现代工具也提供了许多其他可视化效果（UML类图，实体关系图，Spring beandocs [2]，Struts / JSF流程等）。
这是DDD模式的第一个：模型驱动的设计。 这意味着能够将模型中的概念（理想情况下完全按字面意义）映射到设计/代码的概念。 模型的改变意味着代码的改变。 更改代码意味着模型已更改。 DDD并不要求您使用面向对象对域进行建模-例如，我们可以使用规则引擎来构建模型-但鉴于主要的企业编程语言是基于OO的，因此大多数模型本质上都是OO。 毕竟，OO是基于建模范例的。 模型的概念将表示为类和接口，职责将表示为类成员。
沟通语言
现在让我们看一下域驱动设计的另一个基本原理。回顾一下：我们想构建一个域模型来捕获正在构建的系统的问题域，并且我们将在代码/软件工件中表达这种理解。为了帮助我们做到这一点，DDD提倡领域专家和开发人员使用模型中的概念有意识地进行交流。因此，域专家不会根据屏幕或菜单项上的字段来描述新的用户故事，而是谈论域对象所需的基础属性或行为。同样，开发人员也不会谈论数据库表中类或列的新实例变量。
严格执行此操作，我们将开发一种无处不在的语言。如果无法轻松表达一个想法，则表示领域模型中缺少一个概念，团队将共同努力找出该概念是什么。一旦建立了该概念，屏幕就会出现一个领域或数据库表的列上的新字段便会随之出现。
像大多数DDD一样，这种开发无处不在的语言的想法并不是一个真正的新想法：XPers称其为“名称系统”，并且DBA多年来一直将数据字典放在一起。但是无处不在的语言是一个令人回味的术语，并且可以出售给商务和技术人员。现在，“整个团队”敏捷实践已成为主流，这也变得很有道理。
模型和上下文...
每当我们讨论模型时，它总是在一定范围内。通常可以从使用该系统的最终用户集合中推断出此上下文。因此，我们有一个部署到交易员的前台交易系统，或一个超市收银员使用的销售点系统。这些用户以特定的方式与模型的概念相关，并且模型的术语对这些用户有意义，但对于上下文之外的任何其他人则不一定。 DDD将此称为有界上下文（BC）。每个域模型仅存在于一个有界上下文中，而有界上下文恰好包含一个域模型。
我必须承认，当我第一次了解有界上下文时，我看不出要点：如果BC与域模型同构，为什么要引入一个新术语？如果只有最终用户与BC进行交互，那么这个术语也许就不需要了。但是，不同的系统（BC）也彼此交互，发送文件，传递消息，调用API等。如果我们知道有两个BC相互交互，则我们必须注意在一个概念之间进行转换：域和其他域。
在模型周围放置明确的边界还意味着我们可以开始讨论这些BC之间的关系。实际上，DDD标识了BC之间的一整套关系，以便我们可以合理化在需要将不同的BC链接在一起时应该采取的措施：
- 已发布的语言：交互的BC商定一种共同的语言（例如，企业服务总线上的一堆XML模式），通过它们它们可以彼此交互。
- 开放主机服务：BC指定任何其他BC可以使用其服务的协议（例如RESTful Web服务）；
- 共享内核：两个BC使用通用的代码内核（例如，库）作为通用的通用语言，但否则以其自己的特定方式来完成其他工作；
- 客户/供应商：一个BC使用另一个服务的服务，并且是另一个BC的利益相关者（客户）。因此，它可以影响该BC提供的服务；
- 遵循者：一个BC使用另一个服务，但不是该另一个BC的利益相关者。因此，它使用“原样”（符合）该BC提供的协议或API；
- 反腐败层：一个BC使用另一方的服务，而不是利益相关者，但其目的是通过引入一组适配器将一个BC依赖的BC的变化所产生的影响降至最低，即反腐败层。使用反腐败层，可以降低依赖风险，特别是在与旧系统集成时，至少实现反腐败层比重新实现该旧系统性价比要高很多。
DDD建议我们绘制一个上下文图，以识别我们的BC和我们依赖或依赖的BC，并确定这些依赖的性质。
所有有关上下文映射和BC的讨论有时都称为战略DDD，这是有充分理由的。毕竟，考虑一下BC之间的关系是很政治的：我的系统将依赖于哪个上游系统，我是否容易与它们集成，我对它们有影响力，我信任它们吗？下游也是如此：哪些系统将使用我的服务，我如何将我的功能作为服务公开，它们对我有影响？一旦产生误解，应用程序很容易失败。
图层和六边形
现在，我们开始向内考虑我们自己的BC（系统）的体系结构。从根本上讲，DDD只真正关心域层。
当然，我们多年来一直在构建多层系统，但这并不意味着我们一定很擅长。确实，过去有一些主导技术-比如EJB ，所有业务逻辑似乎都渗透到应用程序层甚至表示层中，留下一组数据实体类作为数据持有者，也就是所谓的贫血模型。这不是DDD的意思。
分层架构是一种历史悠久的架构，通过分层架构，可以将系统按不同职责组织成有序层次，由于这种划分往往比较容易界定，也算是最常见和最受欢迎的一种架构，有一个说法是：“如果你不知道要用什么架构，那就用它。
当我们说一个系统是分层架构的时候，你可以把这个软件想象成一个有很多层的蛋糕的样子，其中每一层放在它的下一层上。较高层使用诸多较低层定义和提供的服务，但较低层并没有察觉较高层的存在。另外，每一层都会对其上层隐藏更低的层。
分层体系结构的一个缺点是，它建议线性依赖关系的堆叠，从表示层一直到基础结构层。但是，我们可能希望在表示层和基础结构层中支持不同的实现。
因此，不是将我们的应用程序视为一组图层，而是将其视为六边形，如图所示。六边形的内部代表了application和domain层。外部代表应用的驱动逻辑、基础设施或其他应用。内部通过端口和外部系统通信，端口代表了一定协议，以API呈现。
图：六角结构
按照领域分层的模型，在应用层和领域层内置后，一个典型的六边形架构应用有两个口子，一个入口对应用户接口层，用于应用控制，一个出口对应数据访问层，用于数据获取和持久化。每个口子都可以对应几个适配器，该应用可以被自动化测试，系统层面的回归测试，用户交互操作，远程HTTP调用，REST调用或者其他。在数据方面，通过配置使用外部的数据库，可以是Oracle数据库，mock的数据库，测试数据库或生产数据库，从而实现应用和外部数据库的解耦。
另外值得一提的是，在六边形架构中，自动化测试和用户具有同等的地位，在实现用户界面的同时就需要考虑自动化测试。它们对应相同的端口。六边形架构不仅让自动化测试这件事情成为设计第一要素，同时自动化测试也保证应用逻辑不会泄露到用户界面，在技术上保证了层次的分界。
