终于明白了,有时候不得不写一些晦涩难懂的代码,其实都是因为分析时漏掉了一些深层次的概念才导致的,缺少概念,就必然导致用一些复杂的操作去弥补
比如,一个付款的业务,你现有的概念是银行账户,目标账户,和一些验证机制,如果没有发掘一个位于这些概念之上的高层概念,就会导致你的账户具有一个复杂的方法(当然也可能是目标账户),这个方法负责验证,付款,收款等,而从业务领域的视角来看,收款不属于个人账户的职责,付款不属于目标账户的职责,这个事务的操作,应该是一个高层概念(比如交易平台)的职责,
这个方法对(交易平台)来说,很自然,不晦涩
对个人账户而言,只负责付款的职责,也不晦涩
对目标账户而言,只负责收款,也不晦涩
所以:在你不得不写一些不那么自然,感觉理由不那么充分的代码时,请首先考虑是否缺失了概念
有的概念很隐晦,需要你去挖掘,这经常是一两拨千斤的效果
"如果某个关键概念在破解谜团时缺失了，其他的事物就不得不替代它完成它的功能。 这会让某些对象变胖，给它们增加了一些本不应该属于它的行为。 设计的清晰度受到了损害。 努力寻找是否有缺失的概念，如果找到一个 ，就将它显现出来。 对设计做重构，让它更简单、 更具灵活性。 "
"如何发现一个深刻的模型（ incisive model），这个模型能够捕获到领域专家头脑中微妙的概念，并且以此来驱动实际的设计。 一个忽略肤浅的表面内容且捕捉到基本内容的模型是一个深层模型（ deep model）。这会让软件更加与领域专家的思路合拍，也更能满足用户的需要。"
"创建一个对象可以是它自身的主要操作，但是复杂的组装操作不应该成为被创建对象的职责。 组合这样的职责会产生笨拙的设计，也很难让人理解。"
------DDD Quikly