Martin Fowler在《企业应用架构模式》一书中写道：
I found this(business logic) a curious term because there are few things that are less logical than business logic.
初略翻译过来可以理解为：业务逻辑是很没有逻辑的逻辑。
的确，很多时候软件的业务逻辑是无法通过推理而得到的，有时甚至是被臆想出来的。这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解。而在具体编码实现时，除了应付业务上的复杂性，技术上的复杂性也不能忽略，比如我们要讲究技术上的分层，要遵循软件开发的基本原则，又比如要考虑到性能和安全等等。
在很多项目中，技术复杂度与业务复杂度相互交错纠缠不清，这种火上浇油的做法成为不少软件项目无法继续往下演进的原因。然而，在合理的设计下，技术和业务是可以分离开来或者至少它们之间的耦合度是可以降低的。在不同的软件建模方法中，领域驱动设计(Domain Driven Design,DDD)尝试通过其自有的原则与套路来解决软件的复杂性问题，它将研发者的目光首先聚焦在业务本身上，使技术架构和代码实现成为软件建模过程中的“副产品”。
DDD总览DDD分为战略设计和战术设计。在战略设计中，我们讲求的是子域和限界上下文(Bounded Context,BC)的划分，以及各个限界上下文之间的上下游关系。当前如此火热的“在微服务中使用DDD”这个命题，究其最初的逻辑无外乎是“DDD中的限界上下文可以用于指导微服务中的服务划分”。事实上，限界上下文依然是软件模块化的一种体现，与我们一直以来追求的模块化原则的驱动力是相同的，即通过一定的手段使软件系统在人的大脑中更加有条理地呈现，让作为“目的”的人能够更简单地了解进而掌控软件系统。
如果说战略设计更偏向于软件架构，那么战术设计便更偏向于编码实现。DDD战术设计的目的是使得业务能够从技术中分离并突显出来，让代码直接表达业务的本身，其中包含了聚合根、应用服务、资源库、工厂等概念。虽然DDD不一定通过面向对象(OO)来实现，但是通常情况下在实践DDD时我们采用的是OO编程范式，行业中甚至有种说法是“DDD是OO进阶”，意思是面向对象中的基本原则(比如SOLID)在DDD中依然成立。本文主要讲解DDD的战术设计。
本文以一个简单的电商订单系统为例，通过以下方式可以获取源代码：
git clone https://github.com/e-commerce-sample/order-backend
git checkout a443dace
在讲解DDD之前，让我们先来看一下实现业务代码的几种常见方式，在示例项目中有个“修改Order中Product的数量”的业务需求如下：
可以修改Order中Product的数量，但前提是Order处于未支付状态，Product数量变更后Order的总价(totalPrice)应该随之更新。
1. 基于“Service + 贫血模型”的实现这种方式当前被很多软件项目所采用，主要的特点是：存在一个贫血的“领域对象”，业务逻辑通过一个Service类实现，然后通过setter方法更新领域对象，最后通过DAO(多数情况下可能使用诸如Hibernate之类的ORM框架)保存到数据库中。实现一个OrderService类如下：
@Transactional public void changeProductCount(String id, ChangeProductCountCommand command) { Order order = DAO.findById(id); if (order.getStatus() == PAID) { throw new OrderCannotBeModifiedException(id); } OrderItem orderItem = order.getOrderItem(command.getProductId()); orderItem.setCount(command.getCount()); order.setTotalPrice(calculateTotalPrice(order)); DAO.saveOrUpdate(order); }这种方式依然是一种面向过程的编程范式，违背了最基本的OO原则。另外的问题在于职责划分模糊不清，使本应该内聚在Order中的业务逻辑泄露到了其他地方(OrderService)，导致Order成为一个只是充当数据容器的贫血模型(Anemic Model)，而非真正意义上的领域模型。在项目持续演进的过程中，这些业务逻辑会分散在不同的Service类中，最终的结果是代码变得越来越难以理解进而逐渐丧失扩展能力。
2. 基于事务脚本的实现在上一种实现方式中，我们会发现领域对象(Order)存在的唯一目的其实是为了让ORM这样的工具能够一次性地持久化，在不使用ORM的情况下，领域对象甚至都没有必要存在。于是，此时的代码实现便退化成了事务脚本(Transaction Script)，也就是直接将Service类中计算出的结果直接保存到数据库(或者有时都没有Service类，直接通过SQL实现业务逻辑):
@Transactional public void changeProductCount(String id, ChangeProductCountCommand command) { OrderStatus orderStatus = DAO.getOrderStatus(id); if (orderStatus == PAID) { throw new OrderCannotBeModifiedException(id); } DAO.updateProductCount(id, command.getProductId(), command.getCount()); DAO.updateTotalPrice(id); }