所做的系统是一个连接到外部信息发送和搜索引擎调用服务的Web前端系统。系统与外部的接口使用的是一层Service外观进行包装，原先的设计目的是使用服务层剥离对外部系统的强依赖──解耦，同时还希望使用Service将系统的商业逻辑集中存放──提高复用的可能。但是实际上我们发现Service这样的抽取方法并没有提高代码的复用度，反而造成数据结构和其算法的大量重复。经过分析，发现由于使用了大量的Hash结构存放接口间的返回结果，造成数据与其Service内部的行为分离，传递后商业逻辑就出现了重复（这样的结果是引入大量Quick but dirty的解决方案所欠下的技术债造成的）。所以我和我的Pair绝对对其进行DDD（领域模型驱动设计）的重构。
领域模型驱动设计和面向对象设计在代码的抽象上很相似，它们都推荐让数据结构（状态）与商业逻辑（行为）统一管理。这样数据的状态与行为就不会分离，这样可以很大的减少由于商业逻辑分散造成的代码重复。这可以让我们实现我们非常重视的DRY（Don’t repeat yourself）。
一开始我们尝试的是找到重复的商业逻辑和其对应的数据结构，然后尝试让它们映射到我们的领域模型。这样的效果还不错，但是经过了一天的工作，我们发现我们对领域模型的理解有问题，我们居然抽取出了重复的领域模型类。这个时候暴露的问题是我们对系统的领域模型没有统一和深入的认识。
所以下一步我们计划进行领域模型语言的讨论会，目的就是使用自己的“领域语言”描述系统的所有行为，从这样的领域故事中找到我们的领域模型（领域概念模型，不是具体编程的时候的类）。
领域模型讨论会最好由最熟悉领域模型的人起草，可以由这个人把它写在白板上。领域的故事最好能够涵盖系统的主要行为，描述要使用简练的语言。一般来说IT系统的内部行为可能很复杂，但是到了领域高度还是可以用比较简单的语言描述的，如果遇到一块白板不够的话最好首先考虑提高观察的高度，让领域的描述简练一些，其次再考虑扩展到第二块白板。在这个过程中我们要注意消除歧义，比如同样一个“术语”在两个功能区域中出现，那我们就要妥善的给他们各自取一个容易区分的“领域术语”作为名字。还有就是我们应该在写领域故事的时候考虑领域模型（或者理解为系统模块的抽象）之间的交互关系，最好在写领域故事的时候对行为的归属（它会指导行为到底会被建模在哪个领域模型中，可以体现为类的调用关系，哪个类持有交互逻辑）达成共识，这个时候达成的共识比在做具体的OO设计时候分辨商业逻辑归属要更体现商业价值。完成领域故事后我们要找到其中的所有领域模型（也就是前面说的领域对象和领域中的术语）。然后团队最好一起通读这个用户故事，一起讨论是否通顺（行为是否完备，抽象是否合理），是否有遗漏（遗失的领域模型或行为）。对于有外部系统的情况下，即使外部系统是面向消息的（或者说是没有使用领域模型驱动的SOA接口），那么团队最好对消息的内容有一个讨论，对其中设计到本系统和外不系统的领域模型进行认领，然后使用一个适配器来保证数据到达系统后就使用领域模型表示，外不系统的数据（一般没有行为）最好也使用一个领域模型进行约定。
完成了上面这一步后，DDD最重要的一部分就完成了，它可以实现系统领域模型自顶向下的“名正言顺”，减少在自底向上的重构过程中产生的大量重复领域模型。下面的重构过程就是给领域模型写测试，使用TDD（或者也可以用BDD的方式提早对行为做验收测试，用它们来驱动对领域模型的实现，其实对领域模型的TDD和BDD是殊路同归）的方式逐一实现领域模型。而后争取给系统写一些验收测试或者高级别的集成测试，再逐一替换这些领域模型。这样就达到了DDD重构的效果。