之前写过一系列的 OpenExpressApp 的文章，到现在OEA的源码下载人次已经上万了，大部分人估计还是抱着学习的态度来使用这个框架。毕竟时间和人力有限，OEA本身也比较复杂，能做到现在我也基本满意了， 我们将继续不断应用 模型驱动软件工厂 的软件工程概念， 坚持 让业务工程师开发应用 （ make business engineers develop applications ） 的理念 ，改善我们的开发过程， 提高开发能力。
为了让团队更好的认识OpenExpressApp，我将在这里再次概要的介绍一下OEA，并粗略的说一下下步的计划，以便大家有个一致的方向。
理念
make business engineers develop applications
目标
令人骄傲的支持大中型企业的信息系统 业务开发平台
OpenExpressApp 总体介绍
OpenExpressApp 不只是纯粹的技术框架，也不只是DSL，而是我之前介绍过 平台分类：系统平台、开发平台和开放平台 中的业务开发平台， 它是在系统平台之上，提供在 开发方法 指导下，通过 开发工具 、 辅助工具 ，基于 框架 、 引擎 以及内置的 模块 等一套支持软件 开发生命周期 的完整开发环境来构造软件，以期在统一平台下能够快速高质量的提供产品。
OpenExpressApp的目标是做成一个 模型驱动软件工厂 ，它将现有技术和产品中有价值的部分引入到一起，它要做的是整合别人已经实践的方法来提高我们自身的开发能力。不同于以往为特定开发角色提供独立的开发工具和框架，它为 业务工程师 、架构师、开发和测试人员提供的一种集成的开发平台。OEA基于业务模型驱动开发指导思想，内置从 企业架构 、 业务建模 、 领域建模 到 应用建模 和 部署 等一系列相关的模型，并提供 报表 、 流程 、 元数据 等基础引擎以及 权限 、报表、 门户 等多个通用应用模块。为了支持软件开发，还提供基于敏捷思想、软件产品线工程的软件 项目管理工具 、 快速原型工具 和 自动化测试工具 等支持。
OpenExpressApp 的关注点是......
-
不 仅 仅 关注开发人员，更关注业务工程师的使用 ： make business engineers develop applications
OEA关注的是开发中涉及到的大部分角色，区别于其他的是更为关注业务工程师，这里我定义的业务工程师是介于领域专家和开发人员之间的一种角色，他会使用 结构化的建模方法 来分析、设计领域知识，做到更早更快的向客户和开发人员传递产品价值。
-
不仅
仅
关注
领域架构
，还关注
软件产品线工程
和
模型驱动
开发
等软件工程领域
- 不仅 仅关注 代码实现阶段，还是支持 软件全生命周期过程的 企业架构 、 敏捷管理 、 原型开发 的 方法和集成化的 工具
开发计划
考虑产品过程中的具体应用，会有以下开发计划：
- 支持审核工作流
- 支持B/S应用
- 一个适合大中型用户的DDD的领域架构
- 支持系统工作流microFlow
- 用户驱动的应用：提供预定义组件，由用户自定义界面和功能
- 建模支持
- 工具开发：支持TOGAF9的企业架构工具、快速原型工具、Scrum敏捷开发项目管理工具、自动化测试工具
- 产品线工程的可变性管理
- .......
一些考虑点
-
领域框架
基于什么平台来做？
现阶段还是在.Net平台的OEA框架下继续完善，考虑JAVA下的企业级应用开源资源比.Net较为丰富，不排除后续会同时支持两个平台 -
建模支持
是参考MetaEdit+来做还是使用Eclipse EMF来做？
这个还一直没有拿定主意，这几天在思考这个问题，由于现在我对实现一个成熟的模型平台的未知东西还是较多，可能会先考虑使用EMF先实现一个TOGAF9的建模工具，然后再做评估
我们需要什么......
在上面的介绍中没有具体的技术语言，也没有具体的设计架构，它涉及的内容也很多，从软件工程到软件技术，从具体开发到开发方法，这都需要进行大量的学习。就像在 MDSF：访谈Mendix研发负责人Johan den Haan 说构建一个成功的MDD工具的关键是有一个优秀的团队，每个成员都可以独挡一面，并且能够很好的进行团队协作。
OEA虽然已经在实际项目中应用了，但它还像个婴儿，它才刚起步，它的每一个知识方面都需要投入很多，更难得是要整合起来，它的成长还有很长的路要走，需要每个关心它的人不断付出努力。 我们每个人都应该有积极和开放的心态、高度的技术热情和责任心 ， 共同的理念和目标： 坚持 make business engineers develop applications 的理念，做出一个让人骄傲的支持大中型企业的信息系统业务开发平台。
