本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

应用层是将领域模型与查询或修改其状态的客户端分离的地方。Application Service是这一层的构建块。正如Vaughn Vernon所说：“Application Service是领域模型的直接客户端”。你可以将Application Service看作为外部世界（HTML表单、API客户端、命令行、框架、UI等）与领域模型之间的联系点。思考一下你系统中向人们展示的最上层的use cases，这会对你有所帮助，例如：“以游客身份进行注册”、“以登陆者的身份购买产品”等等。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

为了与领域对象进行交互，你需要持有该对象的引用。实现这样的一种方式是通过创建对象来实现。或者，你可以贯穿关联，在面向对象编程中，对象持有与其他对象的引用，这使它们贯穿，从而有助于我们的模型的展现。但是，你需要有一种机制来获取第一个对象：聚合根。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

工厂是一个强有力的抽象。它们帮助客户端从如何与领域交互的细节中解耦出来。客户端不需要知道如何去构建一个复杂的对象和聚合，所以你可以使用工厂来创建整个聚合，从而让其具有不变性。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

聚合可能是领域驱动设计中最困难的构建块。它们很难理解，甚至难以正确设计。但是不用担心，我们在这里给你提供帮助。在进入聚合之前，我们需要先了解一些关键概念：事务和并发策略。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

我们已经讨论了先尝试将领域中的所有东西构建为Value Object的好处。但是当领域建模时，可能你会遇到这样的情况，通用语言中的一些概念需要有一些Identiy。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

你已经了解了实体和值对象了。作为基本构建块，他们应该包含了任何应用的大部分业务逻辑。但是，在一些场景中值对象和实体并不是一个最好的解决方案。让我们看一下Eric Evans在他的《Domain-Driven Design: Tackling Complexity in the Heart of Software:》书中说的话：

当领域中的一个重要过程或转化不是实体或者值对象的自然职责时，增加一个操作作为一个单独的接口，此时该接口被声明为Service领域服务。根据模型的通用语言定义接口，并确保名称是通用语言中的一部分，是服务成为无状态。

本篇博文由本博客(http://www.veitor.net)经原文翻译，转载请注明出处。

通过使用self关键字，我们不会将”值对象”作为领域驱动设计的基本构建块，而是在代码中将它们作为你通用语言的概念。一个值对象在你的领域中不仅仅是一个东西，它能够度量、量化或者描述一些信息。值对象可以看作是小的简单对象（如金钱或者日期范围），它们不像实体（Entity）通过身份标识来进行区分，而是根据其所持有的内容来做区分。

SNI：在同一个IP地址上运行多个SSL证书

什么是Server Name Indication(SNI)？SNI是SSL的重要组成部分，它允许多个网站存在同一个IP地址上，如果没有SNI，每个域名都需要有自己的一个IP才能安装SSL证书。然而，SNI解决了这个问题。

背景

你已经应用了一个服务一个数据库的模式，每个服务都有自己的数据库。但是一些事务需要跨服务，因此你需要一种机制来保证跨服务的数据一致性。假设你正在建设一个电子商城，客户有其信用额度。应用必须确保新订单不会超过该客户的可用额度限制。因为订单和客户信息在不同的数据库中，因此应用不能简单的使用ACID事务。

背景

我们假设你正在使用微服务架构来开发一个在线商城应用。大多数服务需要用某种数据库来持久化数据，如：订单服务存储关于订单的数据，客户服务存储客户相关的数据。