在面向对象程序中，用户界面、数据库和其他支撑性代码常常直接写进业务对象。而新增的业务逻辑又会嵌入到界面组件和数据库脚本中。这是因为从短期来看，这样做最简单。
当与领域相关的代码扩散到大量其他代码中时，就会变得非常难以理解和推断。表面上看来仅仅是针对用户界面的修改，实际上会改变业务逻辑。为了修改一条业务规则，可能就要对用户界面、数据库代码，或其他程序元素进行细致的跟踪。无法真正实现一致的、模型驱动的对象。自动化测试也会非常困难。由于做每件事都涉及到所有的技术和逻辑，程序一旦复杂起来，就会变得不可理解。
因此：
将表达领域模型和业务逻辑的代码与其他代码隔离开来，并消除他们对基础设施、用户界面，以及非业务逻辑的应用逻辑的依赖。把复杂的程序划分为若干层。使每一层的设计具有内聚性，并且只依赖于下面的层。通过各种标准架构模式与上面的层保持松耦合。将与领域模型相关的代码全部集中在同一层中，并将其与用户界面层、应用层和基础设施层的代码隔离开来。领域对象无需承担对自身的显示和存储，以及管理应用任务等职责，从而能够专注于表达领域模型。这样，模型就可以演进得足够丰富和清晰，以体现业务知识的本质并使其得以运作。
这里最关键的目标就是隔离。要避免在表达领域模型时，依赖或引用其他系统关注点。对于这一点而言，相关的模式，例如“六边形架构”，可以起到相同或更好的作用。