那一天，人们终于回想起了被BUG支配的恐惧
《架构整洁之道》里面有一句话定义业务逻辑
严格来讲，业务逻辑就是程序中那些真正用于挣钱/省钱的业务逻辑与过程。更严格得讲，不管这些业务逻辑是计算机上实现的还是人工实现的，他们在省钱/赚钱上的作用是一致的
软件开发通常被应用到真实世界中已经存在的自动化流程。从一开始，我们就必须明白软件脱胎于领域，并且跟领域密切相关。在我们开发软件的时候，当然也可以直接坐下来敲代码，但仅限于在开发价值不大的软件时。
为了创建一个复杂的软件，你必须知道这个软件究竟是什么，在你充分了解金融业务是什么之前，你是做不出一个好的银行业软件系统的，你必须理解银行业的领域。
没有丰富的领域知识能做出复杂的银行业业务软件吗，没门！那谁了解银行业业务呢？软件架构师吗？不，他只是用银行来存储自己的金钱，软件开发人员？别为难他了。只有银行业务人员才是这个领域的专家，他们知道所有的细节，所有的困难，以及所有的规章。这些就是我们永远的起始点：领域
模型是软件设计中最基础的部分，我们对领域的所有思考过程被汇总到这个模型中，我们需要就这个模型跟领域专家就进行交流，跟资深的设计人员进行交流，跟开发人员进行交流，模型是软件的根本。要表现这种模型，常见的方式是将模型图形化：图，用例等。我们需要用模型交流。
软件设计有不同的方法，其中之一是瀑布设计法。这种方法包含了一些阶段，业务专家提出一堆需求同业务分析人员进行交流，分析人员基于那些需求来创建模型并将结果传递给开发人员，开发人员根据他们收到的内容开始编码。瀑布设计法中知识只有单一的流向。这种传统方法虽然应用很多年，但是还是有一定的缺陷和局限。主要是业务专家得不到分析人员的反馈信息，分析人员也得不到开发人员的反馈信息。
另一个方法是敏捷方法学，这些方法不同于瀑布方法的一堆动作，产生背景是预先很难确定所有的需求，特别是需求经常变化的情况。敏捷开发试图解决另一个问题被称为"分析瘫痪"，团队成员会因为害怕做出任何设计决定而无济于事。敏捷开发者反对预先设计，相反，他们应用大量的灵活设计。敏捷开发也有自己的不足，
敏捷开发缺乏真实可见的设计原则，由开发人员执行持续重构会导致代码难以理解或者难以变更。瀑布流会过度工程，过度工程可能会带来另一种担心：害怕做出深度，彻底的设计。
本书介绍领域驱动设计原则，这些原则会增进对领域内复杂问题进行