上QQ阅读APP看书，第一时间看更新
问题、问题、问题
DDD作为一种架构方法，最大的突破应该说是非常明确地区分出了问题域和解决方案域。而认知问题这件事情绝对不是技术人员擅长的，从我们学习编程起，我们就被如设计模式（Design Pattern）这样的解决方案所包围。想当年我自己最得意的事情也是refactor to pattern，也是把解决方案当成了“终极问题”来追求。
这往往是一个痛苦的蜕变，需要有人在你身边不停念叨“你说的问题是什么？”。你必须要做到心平气和，即使你认为对方是故意挑衅，有时候挑战更能促进思考上的突破。比如我经历过下面的一段经典对话：
甲：我认为这个子问题域是客户账户管理的问题。
乙：我觉得你已经在说解决方案了。
甲：客户账户管理是问题，我并没有提怎么管理啊！
乙：谁说一定要管理客户？！我还是觉得你说的是解决方案！
甲：（受不了你了… …）不管理客户我们做这个系统干啥？
乙：我就是这个意思啊，为啥要做这个系统？我们解决了什么业务问题？
甲：这么说的话那把业务找过来，看他们怎么说。
乙：行，反正DDD里说领域专家很重要，业务来了再讨论。
某种意义上这两位技术人员的争论是卓有成效的，最终的发现是业务问题其实并不清楚，远没有达到可以进入解决方案建模讨论的时候。