最近一个dish项目的建设思考

1. 系统通用能力的沉淀：a.核心模型的数据沉淀 b.通用服务能力的沉淀

   ps1：以前重心主要放在了业务的抽象和通过设计模式来增加可复用的扩展性。局限在于，抽象的范围会被单个业务或者当前的业务所束缚，在更大的范围内，也许所做的抽象就无法很好的起到它的作用。而通用能力的沉淀，在于每个业务项目都会帮助积累一些通用的能力，这些能力可以直接应用到其它的业务项目中，尤其是在一些业务发展前景不是很清晰，业务多样性比较高的场景。 更进一步，随着系统的通用能力的积累和规划，这些能力还会反过来影响和规范业务需求。 最后，所有的能力都有上下文限制，需要明确系统边界。

   ps2：通用能力的沉淀，必然导致数据模型的职能更单一，导致上层的一个业务含义的表达需要聚合很多数据模型，从而大大增加数据操作的复杂度。反过来，数据模型的单一职能，导致了对通用服务能力的依赖，否则一天天写mapper就写死了（这里的通用能力暗指的其实是对聚合操作的通用能力）。

2. 多租户：数据隔离，业务规则可配置化

3. 核心模型的重要性：模型的含义定位，模型的字段，模型之间的关系(聚合)。核心模型和通用能力的基石，对通用能力的影响和非常非常巨大的。根据模型聚合的边界划分，还可以分出不同的应用服务，人员组织架构等等。

4. 系统包结构/模块划分: a. 三层架构(api,业务层,基础建设层(dao,wrapper,util...)) b.四层(api,业务层,领域层,基础建设层(dao,wrapper,util...)) c.根据系统职能的定位，在四层的基础上，对业务层进一步进行拆分(1.首先是业务层整体的划分：a.按照不同的业务 b.对业务流程的抽象 等进行划分等等。 2.然后是每个业务模块下，再可以建设该业务层下的通用层，业务流程抽象划分等等)

   难点：1.业务层的抽象和划分 2. 业务层内部的通用能力和领域层内的通用能力的界限(业务层的划分对这个影响很大)

5. 系统交互：bc端分离(模型异构，bc端的业务区别大)，。。。

6. 以上的这些系统建设的知识是如何积累下来的呢？ 理论+实践？看什么书呢?(领域驱动？企业系统架构？)

7. 为什么在这个系统里，对设计模式的东西感知的很少？是因为业务层划分完之后，每个业务功能都变得太小？是因为业务本身的特点？

8. 胡思乱想：设计模式的目的是帮助我们实现 高可复用的高可维护性。 通用能力的建设，实现了很高的复用性，而且这种核心的通用层一旦建立后很少会需要再去修改。功能的扩展也许因为 数据模型和它本身的单一职能 而变的没有那么高的要求。 再加上业务层进一步的通用化建设和划分得更小，导致了在这种情况下设计模式变得不是那么必要。 所以，设计模式在更加多变，复杂，细枝末节更多的业务层发挥的余地更大。