之前一直想一些编程方面的归类和聚合，没想到这些东西其实早就被人讨论。读书少伤害大。
可能跟自己的方向不一样，不过“领域驱动“DDD，这个，确实在考虑怎么把相关的类放在一起。在面向对象的基础上进行另一层整合。这比普通的分层方便多了。
之前想一个功能，当它再次出现的时候会想把它放到哪个地方合适，方便在下一次出现的时候直接引用。一般都有固定的层去容纳这些功能，有的时候好像分到哪一层都可以又哪一层都不归属。有领域来打破普通的层界限的话会好一点，可能也只是提供了一种思考方式，下一步又徘徊在好像分到哪一个领域都可以好像又都不归属。
图里说，命令查询分离和时间溯源实现领域驱动。命令过来经过控制器进入命令队列，然后被处理并储藏到事件库里，同时更新用于显示的view db。查询的时候直接通过viewdb取或者通过事件库对事件进行回溯，重新计算出来最终结果，以此作为一种确认方法来处理重要严谨的数据查询。
其它部分不是很清楚。这里很有趣的一点是，计算机处理了一种人的业务流程。大体就是，对重要事情进行确认的时候，会追溯排查变动历史。本来机器更新已经能确定最终结视图是正确的，可是对重要事件还是进行一次类似人的习惯，重新排查计算，根据历史记录。这样可以增强一些确保同时减轻了更新viewDB处理时的严谨度。显得程序好设计一些。 之前没有想过有类似的做法，这种处理比较顺应人的思考，对程序运转和编程过程都有很好的帮助。
领域的分话题有些多，主要的还是用来聚合一些功能方便更改和维护。图中的领域视图可能用来处理一些偏向银行的特殊业务，使得事情的业务逻辑把框架影响成这幅特殊的样子。一般一些其它场景可能不好理解它在做什么，我就不是很理解。
关于领域 查询和命令分离这种做法，还是有些觉得有可以继续优化的空间。或许读书少的我没有发现已经有这样一些方法了，只不过换了个老夫没听到过的名词。
领域本来就是做相关功能的聚合，查询也涉及到一些业务逻辑，也可以做成一些相关查询的聚合。这些处理就像软件里有一个个部门，每个部门负责特殊的事情。或者说没有软件的话，这些事本来就是由一些相交互的部门，部门里各种人员的职责任务，来完成。计算机取代了其中需要重复和计算的部分，业务的处理流程并不需要再次构思。顺应本来应该有的人的思考过程就可以了，也就是对业务的处理、对待过程。之前只想过靠稳定的计算来直接分配任务到各个类，没有想过计算也可以被设计成不稳定的，重要数据可以像现实中一样通过再次核算来确保。
或许这也并不是什么重要的功能，仍然会给人眼前一亮。
查询和业务分离不是那么合适，查询也是业务的一部分，也是由一个部门负责。这个部门为了导出查询数据需要从其它很多部门汇集数据。这个部门对汇集数据的处理 以及 对汇集过程中和各个部门的交互 都是它的固定业务。或者不同的查询部门导出不同的数据，有不同的作用，和其它每个部门的交互方式也不同。
如果是资源管理业务偏向的视角的话，把聚合体当作是一个部门会比较容易。