从需求到代码

DDD最初吸引我的地方是能够从问题分析一直拉通到代码实现，这有别于很多其它的架构方法，总是在某个链条上产生脱节。所以DDD的经验获取也需要尝试让团队端到端的拉通体验。

然而事实上很多团队仍然在践行着脱节的实践，比如建模后产生的Entity仍然用传统的数据和行为分离的实现方式。这样的实践方式显然是有悖于DDD的初衷，如果不能让业务和系统模型实现绑定关系，很快就会走上各说各话的老路上去。

实践端到端也有一定的技巧，首先应该明确分层架构的原则和规范，比如是否有Application Service存在的必要，Interface的调用规则等等。在此基础上，需要明确守护Domain Model的纪律，时刻保证代码和建模的一致性。最后需要建立分层的测试机制，特别是对Domain层逻辑的守护。

和前两点相比，这真是一个需要全队刻意练习的过程，坚持信念是团队走过开始阵痛期的必要条件。