领域概念：信号隔离
DDD根据业务驱动的SoC理论，通过端口和适配器架构进行了 Adaptor 设计，将系统引用的外部技术与实体业务分离。
要求开发者以业务代码为核心，开发者需要关注业务时，就分离关注业务代码；需要关注外部技术的引用时，就分离关注技术代码。
当外部技术因为一些客观原因更迭时，可以将影响控制在 Adaptor 外部接口中。[1]
整洁架构与领域模型
整洁架构
在先前的一篇文章中（见[1]），描述了六边形架构与整洁架构的意义与价值。一个复杂的软件工程项目中，一般会被
划分为多个不同的领域，每个领域都互相信号隔离。与普通的分层架构不同的是，整洁架构将一切与外部的插口全部置于Gateways域
（Adaptor 外部接口）。Gateways域还有许多职责，分别是
adaptor
对外部技术进行实现, 例如消息队列、缓存、数据库、第三方库。
调用用例域
实现domain域的依赖倒置
用例域的职责是调用Service服务。Service服务类似于协调者，用来协调、调度domain域的各个领域对象的职责、核心业务能力来完成业务功能。
一般domain域是不允许一切框架级依赖的[2]，它保证了最纯粹、干净的领域对象与业务逻辑。如果遇到业务
必须用到第三方技术的情况，运用依赖倒置(Dependency Inversion[3])，domain域提供接口再由Gateways域实现。Gateways域实现时，引用其被分离的外部技术。
整洁架构看上去就是为领域模型量身定制的架构，需要领域模型来实践。
领域模型
领域模型是一种对业务概念的具象化。
在设计上，要求开发者从业务角度出发思考问题。
为了解释清楚这个层面，我们划分三个思考问题的角度：
• 业务角度：根据业务需求设计业务模块及交互关系
• 系统角度：根据业务需求设计系统和子系统的模块
• 技术角度：根据业务需求决定采用的技术及框架
DDD的核心诉求就是能够让业务架构和系统架构形成绑定关系，从而当我们去响应业务变化调整业务架构时，系统架构的改变是随之自发的。
DDD的运用最成功的地方就在于创造业务与系统的认知、语义一致性环境。
开发者需要找到系统中面向业务的核心业务概念，然后将其变为关键的业务对象（领域对象）。界限上下文一般提供了各个子域的语义边界。
各个子域严格地按照其上下文的语义规则来传递信号。
开发者就可以保护业务代码的纯粹性与核心性，将外部的代码隔离只Adaptor中。
信号隔离
信号隔离是领域中的一个很重要的概念。不同的领域间一般也是互相不可见的。但开发者难免会在一个领域中使用另一个领域的代码。
这个时候，需要将被调用方领域的业务代码暴露成一个用例置于用例域。然后调用方领域的Gateways域依赖被调用方领域的用例域，
在调用方领域的Gateways域使用外部技术实现的方式将前者使用Adaptor接口思想接入调用方领域。
这样，其它领域的代码就作为了第三方技术的身份加入了领域中，核心如上面所述——
保护业务代码的纯粹性与核心性，将外部的代码隔离只Adaptor中
[1] 关于六边形架构与整洁架构，详见思考优异的软件设计
[2] 见https://en.wikipedia.org/wiki/Domain_model
[3] 见https://deviq.com/principles/dependency-inversion-principle
[2] 见https://en.wikipedia.org/wiki/Domain_model
[3] 见https://deviq.com/principles/dependency-inversion-principle