大家先不要急着回答我的问题先对比以下落来的3位同学的对“转账功能”的具体实现。1.甲君实现“转账”的代码评论甲君这种实现方式咋看上去并无问题或许很多朋友也都是这样去实现转账功能的包括我在内。2.再看看乙君对“转账功能”的实现的。评论相信看到乙君的实现各位肯定会喊当然是这种比较好啦应该没人会说这种方式比第一种差吧但反问各位这种做法为何好好在哪里为何能驱动出这个模型来或许你们都会答第二种明显维护的时候更省力什么的。。。我只能说从重构的角度来说第一种有必要改进成第二种但从功能实现的角度抱歉我无法单纯从转账这个用例精化出这种模型来。3.看看丙君的“转账实现”评论相信有不少人看到丙君的实现第一反应是这种比前两种貌似都要好因为从代码量来说它是最少的所以大家第一反应都会觉得这种更好而我又反问你们单纯从一个转账功能就能驱动出如何简洁的模型究竟巧妙在哪里每个看过三种实现方式的人都会觉得这种实现方式职责更加分离了更容易维护了更。。。就是说不出如何驱动出来的。其实我也觉得自己表达不清所以题目打了两个字“谜团”只能尽量去描述心中的疑惑已知条件实现转账功能问题结果得出一个Account领域模型结语单从一个这么狭窄的已知条件去驱动出第二种方法的领域模型各位你们凭什么得出这个结果?得出Redraw()和Deposit()方法而第三种方法又凭什么去把赋予Account对象一个转账行为凭什么说转账是一个行为请大家严谨地分析一下。讨论结果经过各位的讨论大致得出以下比较认同的第4种方案见下图。然而虽然说这种方案是大家比较认同的但我本人觉得绿色框框的部分代码是为了替代转入(Deposit)和转出(WithDraw)功能而定义的行为从业务概念理解上很合理也应该这么做但始终有种换汤不换药的感。我会把最新的讨论结果更新上来大家放心讨论和关注此文结果。