一个简单例子：贫血模型or领域模型

第一个问题，重构能够解决部分问题，但不能解决全部问题。我承认对于这个简单的转账例子，如果添加取钱和存钱服务，一个优秀的程序员完全能够提取方法重构来消除代码上的重复，但是请注意，这只是技术上的手段，不是领域的驱动。我曾经参加的一个项目，当我查看现有代码时，发现里面很多重复代码，由于看完《重构》不久，十分想练手，SDM也赞同，于是让我做code review。刚开始很兴奋，但是当消除几个明显的代码重复之后，剩下来的工作越来越举步维艰，很多逻辑相互交织在一起。虽然明显看到其中存在重复，但是却很难使用提取方法来重构，好几次还不得不回复成原来的代码，因为重构后的方法和原来的代码存在细微的不一致。提取后的方法很少具有业务意义，它只是技术上的手段，因此也并有因为重复代码的消除而获得更可理解的代码。对于这种过程化的类，我发现几乎仅有的重构手段就是提取方法，不管是提取到当前类，还是提取到一个外部的工具类。最终的结果是，我的重构实质上并没有带来实质性的好处。我认为，重构需要有领域模型的引导，否则它可能走错方向。

第二个问题，你认为WebUI和WebService接口的Service代码能够重用吗？两者接口的粒度不同，这会导致它们使用的DTO完全不同，要想重用几乎是不可能的。关于我谈到的领域模型的缺点，我坦率的承认实施领域模型有很大的风险，尤其当项目中没有一个人真正懂得领域模型时候。

 我来回答这个问题吧，对于Aggregate Root的概念你可能理解有问题，详细介绍还是请参看Eric Evans的《DDD》，我这里只举一个简单的例子，订单的例子（又被用滥了)。关于Order, LineItem，Product的关系，这里不用说了吧（我讨厌画图），对于Order我们需要单独跟踪它，因为客户有可能去查询某个订单（根据订单号），因此它是一个聚合根。但是对LineItem，我们一般不需要跟踪它，凡是当我们谈论一个LineItem时它必定要和一个Order联系，也就是说有个Order的上下文在，因此LineItem不是一个聚合根，它属性Order这个聚合根。同样我们也需要跟踪Product，我们需要查询所有的Product，需要获得单个Product的信息，因此Product也是一个聚合根。在这里有两个聚合根，Order和Product。按照你的观点（我揣测的），可能认为只有Order这一个聚合根，这是错误的。