面向领域的业务平台设计（一）

毕业后，做了很多年的中间件，有工作流，有数据持久层框架，还有个类似tomcat的server等，一直在思考，一个最适合业务的平台应该是什么样子的。因一直没有业务经验，因此，尽管有一些想法，但是也不知道这些想法靠不靠谱，最近一年参与了一个CRM项目的设计，积攒了一些业务经验，心中的想法逐渐清晰了起来，也有了一些底气，写下来跟大家交流探讨。

就如同变化多端的八卦卦象是由乾、兑、离等8个基本卦象组成，万事万物是由数种原子构成，形态各异的高楼大厦是由砖头和砂浆砌成，应用也有构成其的“元”，即构件。

业务应用是分层的，典型的分层是展现层、流程层、服务层、数据持久层，每一层次的关注点都不同，构件也不相同，比如一个业务逻辑层的构件输出的数据，会通过展现层的构件来展现在界面上。且各层之间的贯通黏合（如MVC中的Controller层就是黏合逻辑），通常要耗费比较多的开发精力，一个好的业务平台，除了在各层次分别提供可复用的构件，需要能够减少各层黏合的工作量。

面向特定领域的业务平台的易用度与其适用面是鱼和熊掌的关系，针对特定领域，要越易用，则平台能力就要越面向特定领域，则越不通用，导致适用面越窄。因此，一个好的平台，要注意分层，比如分成通用的构件和领域化的构件。业务用户可按需使用。同时，还需要在各层次开放定制能力，供业务用户在各层提供领域构件。

现在的产品交付都是解决方案级的交付，解决方案由多个系统或子系统构成，一个部门，一个项目组通常只是提供解决方案中的一个部件，负责端到端的业务功能中的一个环境，因此，需要支持构件的组装，以形成更大粒度的构件，支撑软件复用与集成。

开发一个子系统粒度的构件通常是一件很复杂的事情，如CRM，需求琐碎、变化频繁、不同客户要求不尽相同，如果缺乏一个好的支撑平台，人力成本会很高，TTM也会很长，因此，一个好的业务平台，也需要能够支撑快速的构件开发、定制。

解决构件的组装和集成，已经有比较成熟的技术了，如ESB、SCA等，IBM、Oracle等大厂商都有提供集成化的开发环境和执行环境。但如何支撑构件的开发这块，各大厂商也有支撑，比如在展现层，Oracle有ADF，在流程层，IBM和Oracle都提供了BPM，在service层，IBM和Oracle提供了规则引擎，VMWare的Spring，在持久层，Oracle提供了Toplink，还有就JBOSS大名鼎鼎的Hibernate。所有前面提到的这些都是业务无关的技术部件，且各层之间的靠业务开发人员自己来黏合，还是不够领域化。因此，一个业务平台，仅仅去重复制造IBM、Oracle造过的轮子，是完全没有竞争力的（这里不算成本）。面向特定领域，评判一个业务平台是否优秀的标准是：

1、是否提供了丰富的领域构件？

2、是否能够节省业务开发人员黏合各层的工作量？

3、提供了什么样的机制来应对需求变化？比如有的客户要求多加个字段、加个校验，有的客户要求少个字段、少个校验等等。

待续。。。