Eric Evens的领域驱动设计相当合理，但其概念描述抽象难懂，令无数开发高山仰止，虽心向往之，然愧不能至。
Vaughn Vernon的实现领域驱动设计加入了很多接地气的实现模式，使得一些先行者可以开始依葫芦画瓢。
但仍然有一大批后进者不得其法，我猜测原因是1）战术设计的几个模式不能和大家已有的经验产生共鸣，缺少一个隐喻，2）即便懂了战术设计的几个模式，但缺少一个行之有效的设计套路。
如果从10000米的高空俯瞰领域驱动设计，你会发现他只是众多设计方法论中的一员，也就是说领域驱动设计也是要解决软件设计的问题，而软件设计的关键就是把问题分解归类。我在Rich Hickey的著名演讲【Simple Made Easy】中学到的设计方法就是按照5W1H对问题进行分解归类，因此我尝试了一下用5W1H的思路去映射领域驱动设计的战术设计模式。
where: ApplicationService，Repository
when: DomainEvent
why: Command
who: who triggered this Command
what: based on what to execute the Command, Aggregate, Entity
how: business rules, implementation of Aggregate methods, Domain Service
软件系统的粗略模型是从外界接收信息，进行内部处理，向外界输出信息。Where对应Application Service和Repository，解决信息的来源和去向问题。Application Service把各个渠道的输入转换成领域对象，使用Repository从基础设施加载领域对象，调用领域对象进行业务处理，再用把领域对象的变动用Repository持久化到基础设施。紧扣Where这个主题，就能很好区分Application Service 和Domain Service，Application Service知道信息的来源和去向，知道如何定位领域对象，其他事情统统不应该放进Application Service。
When映射到DomainEvent。业务中发生的重要事件是很好的时间坐标，他是业务过程事后追溯的重要依据。
Why映射到Command，Command的内容能解释为什么发生了一个业务事件。
Who映射到Command的发起方信息。
What映射到执行Command的Aggregate,他能解释Command对象引发的业务决定基于什么状态完成的。
How映射到Aggregate、Domain Service，这里面的逻辑解释了如何根据Aggregate的状态做出业务决定。
Vaughn Vernon在他的实现领域驱动设计中提到过一种业务建模方法Event Storming，很容易操作。思路是DomainEvent->Command->Aggregate，稍加调整就可以成为When->Why->Who->What->How->Where。具体操作方法如下：
1. 按发生的先后顺序罗列DomainEvent
2. 思考每个DomainEvent的起因，列出Command
3. 思考Command背后的角色
4. 思考Command到DomainEvent依据的Aggregate
5. 思考Command到DomainEvent的判断规则
6. 思考从何处获取Aggregate，DomainEvent的接收方是谁。
按照上述的简化方法，初学者也很容易上手领域驱动设计。
