在我以前blog中提到过Mendix，本篇介绍一下Mendix，还是相当有借鉴意义的，对企业级软件开发感兴趣的可以看看。
传统开发方法
传统开发过程中存在多种角色：项目经理、业务人员、需求人员、技术架构师、可用性设计师、程序员、测试人员、主要客户等，这些角色会被严格的区分为两种类型：业务（business）和IT技术人员。业务部分主要负责客户、业务分析、需求工程，而IT部分主要包括开发人员。架构师、测试人员等。总的来说，就是
- 业务对what负责
- IT对how负责
这种方式看起来好像没有问题，但是为什么这么多项目超过时间、超过预算、不能满足需求而失败呢？我们能够责怪大家吗？能够怪需求为什么总是变化的吗？能够怪技术人员为什么不能对复杂业务进行随需应变？答案是明显的：不能。
原因很简单：
- 我们不能预见所有的可能性和复杂性
- 很难把抽象的业务需求很好的转换成精细的IT方案
- 设计、文档和实现不同步
软件工程到业务工程
- 释放业务分析师的能力
现在很多业务分析人员都习惯于使用Visio或者word之类的来编写文档和画流程，在实现过程中很难完整无误的把这些内容转换为实现所需要的东西，如果我们采用一种统一的可视化模型方式来进行业务分析，应用软件大部分功能由业务分析师完成，而剩下的复杂功能由技术人员来解决。 - 减少上市时间
通过可视化的模型，软件会自动化运行和测试 - 提高灵活性
如果我们能在模型级别上考虑可变性，那么更改需求将会更灵活简单 - 防止过时的文档
模型及文档，模型可以被用来运行，所以模型和最终应用程序是100％的同步 - 不重型发明轮子
构建块、模板等都会在应用开发过程中很好的进行累积，不会重头再次处理同样的事情
Mendix 提供软件工具、方法和架构平台来快速建模、构造、测试、继承、部署、管理和优化Service-Oriented Business Applications (SOBA) 。它继承了模型驱动开发和敏捷方法，允许业务分析人员使用可视化模型参与到开发周期中。
与以前开发方法比较
Mendix Model-driven Platform Suite
技术原则
- 提高业务和IT的协作
每个模型都是业务分析师和IT工程师进行沟通的共同语言，分析师可以找到模型是否匹配业务需求，技术人员检查模型是否满足特定技术细节 - 每个DSL都是可以在运行期下直接运行的
模型可以直接被运行，防止代码生成带来的一些维护和测试问题（注：我不清楚它是如何做到无代码的，我想是不是生成一些代码，只是模型部分没有生成代码，这个还有待考证） - 每个DSL都可以扩展为其它第三代编程语言
- 尽量少使用第三代语言
- 开放、可扩展的技术平台，提供可扩展的API访问框架低级别的核心功能
- 开放标准
- 自动化业务流程驱动，业务流程模型是模型的中心
- 服务组件架构（Service Component Architecture）
- 重用，提供可重用的模型、服务、组件等
Mendix Business Modeller: a unified modelling space
模型编辑器
Mendix Business Server
开发方法
本文转自 jingen_zhou 51CTO博客，原文链接：http://blog.51cto.com/zhoujg/522565，如需转载请自行联系原作者
