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