不同于DDD的战略规划，战术规划更偏重于实施的细节，更聚焦于在单个有界上下文中的组件排布并且有各自通用的组件开发标准，在产品开发过程中可能会变更战术规划。

在上节课中，我们讲到了DDD的顶层设计包括了领域规划，各子域规划和域内的通用语言。作为单个子域的设计，有效的域模型是下层规划的关键。

因此下层规划也通常被称为模型驱动设计，与之密切相关的包括服务设计、实体设计、分层架构设计以及值对象。

一个子域就是一个服务，当然子域还可以包含多个微服务，这些微服务的设计是为了更好的理解子域内的业务逻辑。微服务的设计通常以分层的方式实现。比如金拱门的门店服务可以划分为接待层（负责记录客户订单和收银）、调度层（负责订单调度和队列管理）、业务层（负责准备食物）、持久化层（原始食材）。基于这样的分层式结构订单处理得会更加高效，每一层的权责明确，复用度高且可以独立扩展。

值对象是领域中不需要唯一标识的领域概念，通常在业务中，我们不需要区分对象是哪一个，而只关心对象是什么，这样的对象我们认为是值对象。如果两个对象所有状态都一样，我们就认为是同一个值对象，比如地址信息、订单状态信息等。值对象是只读的，具有不变性不能直接修改，但可以被替换。如果我们要修改一个客户的街道信息，应该是Customer.Address address=new Address(); address.Street=; 而不应该是Customer.Address.Street=;

下层设计中的实体对于熟悉数据库设计的开发人员来说一定不陌生，实体可以用唯一ID表示的，由一个或多个值对象组成，通常表现为数据库中的一行并由前端应用的业务逻辑进行增删改查。

实体通常是以集合（Aggregate）的表现形式呈现出来的，从业务角度讲我们不大会关注某一笔具体交易或某一个客户的消费行为，而会从全局角度剖析某类人群或某个区域的市场反应。因此对于客户或订单的关联系统，任何客户或订单的信息更新，都需要立即同步到其关联系统，才能使集合快速更新。

最后，工厂和仓库是用来生产集合的工具，工厂可以不断将实*造成新的集合（通常由函数代码实现）；仓库用来存放各种集合（通常由数据库物化视图实现）。仓库不单单是一个数据访问对象，而是存放部分实体数据并可以对其进行更新。

既然都聊得这么深入了，下集开始，小编会介绍DDD的具体实现。内容上也会加入一些代码段的部分以让开发人员也可以了解领域驱动设计的思想，下期见啦~