平台开发基础原则制定

最近在构想一个新的内部使用平台，发现首先要确立一些的根本性的原则，作为设计指导，使各模块设计人员都能保持一致的方向，只有先确定了这些基础原则，在开发决策时，大家才不会争论不休，包括：
1. 强类型，还是弱类型？Bean对象，还是Map集合?
(1)Map的好处在于：可以统一数据模型，并作为上下文或数据总线处理，可以不用生成代码，就能对CRUD等基本功能，作运行时封装，适合于快速开发。
(2)Bean的好处在于：强类型，明确的契约接口，调用者与被调用者都能很明确的知道需要什么，符合领域驱动设计的思想，便于后期维护，适合于长期产品。

2. 零代码，还是零配置？还是全图形？
(1)像OFBiz等框架，提倡零代码开发，也就是全配置，
通过一个XML，配置一下实体字段，搜索条件，显示列，菜单，工作流等，就能完成大部分资源管理类功能，
在特殊功能时，通过配置回调Java接口，来调用部分Java代码逻辑，
好处就是所谓的简单，不需要懂Java也能开发。
坏处也显而易见，灵活性差，性能差，IDE支持差，重构能力差(需全文搜索)，开发不方便(不能调试)，不能使用继承，多态等面象对象复用功能，程序员不愿意天天写配置，离职率高。
(2)而现在流行的开源项目，都开始提倡零配置开发，通过注解等，尽可能在代码中集中处理，
好处是：IDE支持好，易于重构，易于开发，不需要在配置与代码之间来回工作。
坏处是：与注解框架强耦合，背离IoC/DI的无侵入原则，修改关联时，需重新编译。
(3)像EOS等平台和一些基于UML的MDA设计器，提倡全图形开发，
通常由图形化的业务逻辑，页面功能逻辑，流程逻辑拼装而成，通过生成代码，或者使用一个引擎运行时解析图形配置。
好处是：给人一种绚丽高档的感觉，更易忽攸客户，在简单的增删改查逻辑下，开发方便。
坏处是：与特定的IDE捆绑，成熟的产品不多，通常不稳定，开发繁琐，维护困难，性能差，复用能力差，不能使用多态，继承等，逻辑稍复杂时，看图形蜘蛛网，比看代码更痛苦，程序员抵触，离职率高。

3. 从领域实体生成数据库，还是从数据库导出领域实体？
这里主要是考虑设计人员，是先做领域UML建模，还是E-R建模。
(1)从领域实体生成数据库，可以使领域模型设计更合理，包括组合关系，聚合关系，继承关系等，这样软件的设计也会更合理。
(2)而从数据库导出领域实体，可以使表结构设计更合理，很多人说，数据比程序的生命周期更长，程序不用了，可能数据还在继续使用。
当然，手工映射可以做得更好，但工作量会翻倍。

4. 快速? 高效? 灵活? 稳定? 扩展? 重用? 易于实施?
如果能全部做到，当然最好，但有些特性通常是互斥的，
在平台开发初期就应该确定优先顺序，孰轻孰重。

当然还有其它一些如：开发方式，封装重点，控制粒度，特性权衡，组件选型原则等等，待整理。