而适配器分为两种，主适配器（别名Driving Adapter）代表用户如何使用应用，从技术上来说，它们接收用户输入，调用端口并返回输出。Rest API是目前最常见的应用使用方式，以取消订单为例，该适配器实现Rest API的Endpoint，并调用入口端口OrderService，当然service内部可能发送OrderCancelled事件。同一个端口可能被多种适配器调用，本场景的取消订单也可能会被实现消息协议的Driving Adapter调用以便异步取消订单。
次适配器（别名Driven Adapter）实现应用的出口端口，向外部工具执行操作，例如向MySQL执行SQL，存储订单；使用Elasticsearch的API搜索产品；使用邮件/短信发送订单取消通知。有别于传统的分层形象，形成一个六边形，因此也会称作六边形架构。
4、DDD是一种思想我愚昧的认为，DDD即业务+解耦。大道至简、多么熟悉的场景，因为这就是我们在做的事情，只不过我们可能过于关注使用了什么技术框架、用了哪些中间件、写了哪些通用的class。
实际上DDD如同辩证唯物主义思想一样，哪怕我们在软件项目的某一个环节用到了，只要这个思想为我们解决了实际问题就够了。我们没有必要为了DDD而去DDD，我们一定是从问题中来再回到问题中去。
三、DDD有什么用借助DDD可以改变开发者对业务领域的思考方式，要求开发者花费大量的时间和精力来仔细思考业务领域，研究概念和术语，并且和领域专家交流以发现，捕捉和改进通用语言，甚至发现模型乃至系统架构层面的不合理之处。当然有可能你的团队中并没有相关业务的专家，那么此时你自己必须成为业务专家。
通常来说我们可以将DDD的业务价值总结为以下几点：
你获得了一个非常有用的领域模型；
你的业务得到了更准确的定义和理解；
领域专家可以为软件设计做出贡献；
更好的用户体验；
清晰的模型边界；
更好的企业架构；
敏捷、迭代式和持续建模；
使用战略和战术新工具；
四、如何DDD通过前面的论述，你脑海里面一定闪烁几个词语“领域模型”“解耦”“依赖抽象”“边界”。这些通用的分析方法一定是放之四海而皆有效的。所以我认为当你按照这几个原则进行思考的时候就已经在DDD的路上向前迈进了一步，接下来我们结合界限上下文、Repository这两个最容易被大家所忽略的地方来进一步阐述。
在这些步骤都做完以后，你再决定接下来如何去编码开发。不过我敢肯定，你在这个过程中已经得到了很多高业务价值的东西。
接下来如何去实现，你可以根据实际情况。我觉得战略DDD比战术DDD更重要，我想这就是DDD作为一种思想的神奇所在。如同金庸笔下的少林绝学易筋经一样，一套并无明确招式的内功心法却能打遍武林。
1、界限上下文领域中还同时存在问题空间（problem space）和解决方案空间(solution space）。在问题空间中，我们思考的是业务所面临的挑战，而在解决方案空间中，我们思考如何实现软件以解决这些业务挑战。
问题空间是领域的一部分，对问题空间的开发将产生一个新的核心域。对问题空间的评估应该同时考虑已有子域和额外所需子域。因此，问题空间是核心域和其他子域的组合。问题空间中的子域通常随着项目的不同而不同，他们各自关注于当前的业务问题，这使得子域对于问题空间的评估非常有用。子域允许我们快速地浏览领域中的各个方面，这些方面对于解决特定的问题是必要的。
解决方案空间包含一个或多个界限上下文，即一组特定的软件模型。这是因为界限上下文是一个特定的解决方案，用以解决问题。
通常，我们希望将子域一对一地对应到限界上下文。这种做法显式地将领域模型分离到不同的业务板块中，并将问题空间和解决方案空间融合在一起。
但是在实践中，这种做法并不总是可能的，想像一下，谁没有维护过“毛线团”系统，现在我们就要借助界限上下文来安全的、合理的、快速的理顺这堆交织不清的关系。
很多书籍或者文章讲解DDD，总是说突出应该怎么构建代码包结构，使用什么技术框架。我认为这是不完全适用的，所以我会花较多时间来阐述一下如何借助界限上下文来理顺这堆“毛线团”。