在面向对象的程序中，用户界面(UI)、数据库和其他支持代码，经常被直接写到业务对象中去。在UI和数据库脚本的行为中嵌入额外的业务逻辑。出现这种情况是因为层短期的观点看，它是使系统运行起来的最容易的方式。
当与领域相关的代码和大量的其他代码混在一起时，就很难阅读并理解了。对UI的简单改动就会改变业务逻辑。改变业务规则可能需要小心翼翼地跟踪UI 代码、数据库代码或者其他的程序元素。实现一致的模型驱动对象变都不切实际，而且自动化测试也难已使用.如果在程序的每一个行为中包括了所有的技术和逻辑，那么它必须很简单，否则会难以理解。
| 用户界面层 | 负责向用户显示信息，并且解析用户命令。外部的执行者有时可能会是其他的计算机系统，不一定非是人 |
| 应用层 | 定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题。这个层附负责的任务对业务影响深远，对跟其他系统的应用层进行交互非常必要。这个层要保存简练。它不包括处理业务规则或知识。只是给下一层中相互协作的领域对象协调任务、委托工作。在这个层次中不反映业务情况的状态，但反映用户或程序的任务进度的状态 |
| 领域层 | 负责表示业务概念、业务状况的信息以及业务规则。尽管保存这些内容的技术细节由基础结构层兰完成。反映业务在的状态在该层中被控制和使用。这一层是业务软件的核心 |
| 基础结构层 | 为上册提供通用的技术能力；应用的消息发送、领域持久化，为用户加盟绘制窗口等。提供架构框架，基本结构层还可以支持这四层之间的交互模式 |
在一个复杂的程序进行层次划分。为每一层进行设计，每层都是内聚的而且只依赖于它的下层。采的用标准的架构模式来完成与上层松散关联。将所有与领域模型相关的代码集中在一层，并且家它与用户界面层、应用层和基础结构层的代码分离。领域对象可以将重点放在表达领域模型上，不需要关心他们自己的显示、存储和管理应用任务等内容。这样使模型发展得足够丰富和清晰，足以抓住本质的业务知识并实现它。