小议架构

做了这么长时间的软件了，一直没有好好整理一下架构方面的东西，打算写几篇小文章，好好整理一下。

主要涉及的还是UI层和业务逻辑层 对于 数据层的东西 还是没有怎么好好接触过，一般用orm也差不多了。

首先是UI层，基本上是mvp的 现在在想mvvm转，但是主要的问题还是很少使用view接口来抽象界面。

还是来聊一聊mvvm的模式

mvvm的核心就是vm

vm既有显示层的逻辑(ICommand)，又有领域模型需要暴露的数据(通过属性封装)，然后还需要脱离UI，这里需要考虑弹出窗体这种逻辑，需要抽象一个IGetDialog这种类型的接口，来吧弹出窗体等逻辑封装。

还有就是vm 和 领域模型ENTITY 的关系，通常情况下VM显示的肯定是ENTITY的一个子集，而一般情况下一个VM很可能涉及了多个ENTITY，这个时候大多数做法是直接引用若干的ENTITY,但是最好的方式还是通过ENTITY2VMHelper的方法来解决。

 

其次就是对于业务逻辑层 采用领域模型组织模式。

业务逻辑层应该包含有若干的Factory、manager、service、entity，helper。

 

 

在entity建模时候 应该充分依据业务需求，某个entity也许也是由多个entity组成的(AGGREGATE)，同时要注意 entity不应该包含它本身的序列化和反序列化方法。

AGGREGATE有一系列的规则

根ENTITY应该有全局标识，他最终负责检查固定的规则

AGGREGATE内部的ENTITY具有内部唯一标识。

AGGREGATE外部对象不能引用根ENTITY之外的任何内部对象。如果需要根ENTITY可以把一个ValueObject副本传递给另一个对象。

只有AGGREGATE的根才能通过数据库查询获取，其他对象需要通过内部遍历找到。

总之就是通过AGGERGATE来维护内部其他ENtity的完整性。

譬如一辆汽车是一个根ENTITY,他聚合了 轮胎，发动机，车身等若干ENtity。

一个订单是一个根ENtity 他可能包括了若干的 产品等等。