前一篇，简单介绍了DDD战略模式的提炼问题域，这篇简单介绍它如何塑造应用程序的架构。
1、创建一个模型以解决领域问题
为每一个子域构建一个软件模型以处理领域问题并让软件与业务保持一致。
这个模型并非现实世界的模型，而更多的是构建来满足业务用例需求的一个抽象体，同时仍保持业务领域的规则和逻辑。
为了避免偶发性技术复杂性，模型要保持与基础架构代码的分离状态。
所有的模型都不是同等创建的，最合适的设计模式是基于每一个子域的复杂性需要来使用的，而非将总括设计应用到整个系统。
2、使用公共语言开启建模协作
前面的模型是通过领域专家和开发团队的协作来构建的。而他们之间的通信是使用一种被称为通用语言(UL)的不断发展的公共语言来实现的，以便快捷高效地将软件模型和概念分析模型连接在一起。
软件模型是通过将其结构和类的设计使用与UL相同的术语来绑定到分析模型。
在编码层面所使用的见解、概念和术语会被复制到UL中，因此也就复制到分析模型中。同样 当业务在分析模型层面揭示的了隐藏概念时，这一见解也会被反馈到代码模型中。
3、将模型与歧义和损坏隔离
将模型位于有界的上下文内，形成一个围绕模型的防护边界，并且上下文定义了模型的适用性并确保保留其完整性。
较大的模型可以被划分成较小的模型，并在独立的上下文内定义，其中专业术语存在歧义或者其中可能损坏(如多个团队共同开发)的位于一个工作区域，以便进一步降低复杂性。
这样通过允许总体解决方案的不同模型在良好定义的业务上下文内部逐步发展来达成，就不会带来对系统其他部分的负面连锁影响。
4、理解上下文之间的关系
