快速开发与0代码开发理论及实践（二）：理论基础----OO和领域模型驱动开发
前文提及，要提高开发效率，我们要有：
1. 一套通用的基础框架
2. 一套开发工具，能够根据需求，生成基于基础框架的从数据库到界面呈现的完整系统代码。在这里，有两个基本要求：
-
生成之后的整个系统，要避免当前大多数代码生成机制造成的存在大量冗余代码的现象，应当是简洁，易于复用，易于扩展、易于更改并易于重构，以及便于维护的。
当前有很多代码生成工具（开源的或者商业的）标榜能够如何轻易生成数千上万行的代码，可惜，细看生成的代码，非常不利于在生成的基础上进行变更。例如，在每一个实体甚至数据库表对应的数据访问类中包含增删改查的代码，或者数据库中有对应存储过程，又比如表示层生成特定的界面控件，如列表，单选多选控件等，每一个实体都生成了数个控件，从而导致大量相似但又不同的代码。当然可能这里列举的情况已经算好的了。有好多的生成界面工具直接把代码生成在各个页面中，连提取控件的工作都不做。这种冗余代码最大的问题是，业务实体的逻辑被分散在系统的从前到后多处地方体现，生成的代码越多，越不利于后续开发和维护。
-
开发工具本身，应该也是简洁，易于复用，易于扩展、易于更改并易于重构，以及便于维护的。
首先，开发工具应该是DDD(Domain-driven Design，领域模型驱动设计）的。开发工具首先要做到的事情是能够成为一个需求到设计的桥梁，这实际上应该是设计上的根本理念。不如此，不足以应对复杂的系统；不如此，将不利于我们归纳总结各种不同系统的统一特性。其次，开发工具本身，应该是可插拔的。例如，至少应该采用某种模板引擎，并且，围绕模板引擎有一套灵活但是强大的配置，管理和生成机制。
说到这里，已经开始介入本篇的主题：通用框架的理论基础。这也是上篇留下的一个问题。
不管任何业务系统，都应该是现实中业务行为在计算机系统中的映射。从业务需求的角度来说，任何系统，都应该可以用业务对象（包括他们的关联关系）和业务规则来描述。业务对象好理解，业务规则呢？
“我们可以将业务规则分为三类：全局规则、交互规则和内禀规则。
……
全局规则是指那些对于系统大部分业务或系统设计都起约束作用的那些规则。…… 全局规则是跨用例的规则。
……
交互规则产生于用例场景当中。……不论是活动、状态还是业务对象，它们在活动转移、状态变迁和对象交互时必然会有一些限制性的条件，这些条件就是交互规则。
……
内禀规则是指那些业务对象本身具备的，并且不因为外部的交互而变化的规则。”
------谭云杰 《大象 Thinking in UML》
所以，不管是多么千变万化的需求，对于业务系统而言，都应该可以用业务对象和业务规则去描述。这就是“通用性”的理论基础。我们的工作，就是找到一个合理的手段，基于这个理论基础，完成从现实到计算机的高效、高匹配和简洁地映射。
如何去做呢？
首先，业务对象的映射是最好理解的，但实际工作中却有诸多问题。最常见的，很多企业的各业务系统，是在不同的历史时期，由不同的vendor开发的。在这些业务系统之中，业务对象的映射描述在哪里？有些系统，是在数据库中，在表结构里，在视图里；也就是说，没用一个统一的API能够描述业务对象；而一些比较好的系统，则通过实体类提供了某种程度的业务实体描述，但却不完整，或者在一些层面没有有效传递。例如最常见的，描述了实体都有哪些属性和对应数据类型，却没有描述是否可空，长度限制，大小限制（针对数字，日期），中文（或多语言标示符）标题，校验规则（上面的内禀规则），甚至与其它对象关联的描述等等；这些没有统一描述的内容，将会被分散在系统各不同角落各自实现，例如客户端，服务器端的校验，用选择控件的不同体现关联关系类型（one to many或者many to many），获取列表数据的时候为了指定关联对象及其显示字段，需要在表示层和数据访问层都做处理等等。这些系统，连在自身内部都没有实现对业务对象的统一描述，还谈何系统间的共享？所以近年针对这种情况才提出来了“主数据管理”(master data management)的概念，绝非无的放矢。
所以，这里引入我们的基本观点：业务系统应该有一个统一的主数据API，描述业务对象及其关联关系和内禀规则，供系统各个层级使用，并尽可能减少其它层级对业务对象的分别描述；在需要的时候，可以通过约定的接口和外部系统交互。
为了实现我们的观点，我们的基础框架应该包含主数据API的提供模块和各个层次的合理调用框架；而开发工具则能够用恰当的方式生成针对业务数据的完整描述，以被基础框架引用。在这里顺便一提，始终应该要做到：良好支持需求变更，反复生成主数据描述不应该影响手动添加的其它描述；相辅相成的，针对独特业务需求，能够方便地添加更改删除描述信息。
至于业务规则，上文已经描述了对包含在业务对象描述当中的内禀规则的映射方式。而全局规则，应该包含在基础框架中，和开发工具关系不大（当然这也是技术积累的一部分）。剩下的，需要对交互规则有很好的处理。
实际上所谓“交互规则”，很大程度上就是我们耳熟能详的“业务逻辑”。一直以来，程序员们“只关系业务逻辑的实现”，而不用去花过多精力在其它方面，一直是许多人的奋斗目标。同样的，这也是我们的目标。或者说，这基本上不再是目标，而是一个已经初步实现的里程碑。长期目标是什么？之前提到了，是0代码开发。如何0代码开发呢？应该可以由用户用简单的方式定义业务逻辑（所谓简单的方式，可以是文字描述和简单的图形拖拽），系统自动解析并转化为系统功能。这样做的最大的好处，其实不是解放程序员，而是能够非常方便地争取到更多的客户，并且同时降低开发成本和周期，也就是说在增加销量的同时还能提高生产力，对于企业的发展是有很大的促进作用的。
那么，这个目标是遥不可及的吗？其实，并不是我们想象中的那么遥远。灵活而友好的设计界面+功能完善的业务规则引擎将能在某种程度上实现我们的梦想。诚然，现有的业务规则引擎（尤其是.NET世界）并不十分完善，但也并不是一无所有；相反，我认为这方面我们至少已经有了一个很好的开端（可以了解一下NxBRE这个开源业务规则引擎）。
说了半天，原来0代码开发依然只是在未来，那有什么意义？意义就是，我们可以开始以此为目标，一步一步地接近这个终点。距离这个目标的远近的差别，可能就是在开发效率上数量级的差别。
归纳来说，目前我们应该能够：
一、从需求文档开始，首先分析出业务对象及其关联（继承关系和关联关系），如前文所述，还包括其属性的各种描述，对应设计领域模型。
二、利用开发工具，根据领域模型生成基于基础框架的业务系统。
那么，这个刚刚生成的系统，都具备什么功能了呢？
它应该已经可以以superadmin的身份登陆，并做如下工作：
- 进入设计模式，界面中一侧显示领域模型描述树：
- 可以利用便捷的方式（例如拖拽，把领域模型拖入菜单区域），构造菜单结构
- 可以直接在界面中（譬如说浏览器里）设计权限，权限的输入参数应该包括菜单项，人员各项属性（例如所属部门和职位，角色等），受控资源的各项属性等；输出应该包括针对特定的受控资源（菜单项，某全局或特定页面中的特定实体，特定实体的某特定属性列等等）是否拥有可读，可写的权限。顺带一提，这里的功能利用现有的规则引擎就能够很好的实现充分可定制的预定目标。
- 各种基础设施已经完备，除了上面提到的权限比较复杂之外，其他的日志，历史数据，异常管理，打印等公共功能都应已齐备。
- 每一个领域模型对应的界面，应该已经包含了增删改查的完整功能。所谓完整功能，就是应该已经包含了数据校验，并考虑到了关联实体在增删改查中的不同呈现（最简单的例子，对于一对多关联的关联实体，在增改界面中，应该已经存在一个针对该关联实体的可查询可分页多列显示的多选控件），还有查询也应该已经包含了针对各个字段（包括关联实体的显示字段(display name），具体哪个字段是显示字段，在领域模型描述信息中描述）的设计优良的查询条件输入功能（例如针对文本，数字，日期和选择列表的不同呈现），排序等更应该已经不在话下。
- 界面可以在很大程度上直接在浏览器中自定义，例如用拖拽的方式决定列表的列顺序，表单的控件顺序，还有关联业务实体构造复杂界面的拖拽拼接（例如形成左边区域是父实体，右边区域是一个Tab容器，每一个Tab中是左边选择的父实体对应的某类子实体的这种较复杂界面）。
- 另外一点很重要，如同一直强调的，所有的这些已经自动生成的代码都应该尽可能的少，除了业务对象（领域模型）描述信息，实体类（根据ORM框架的选择，可能还有ORM框架配置信息文件）之外，其余的从前端到后台的各个层次的功能应该都通过读取领域模型信息来实现。
- 还有一点与上面的相关，整个系统的代码架构应该便于基于生成代码基础之上进行更改，不能出现为了增加某实现而需要把已自动生成的其他功能完全废弃的情况。
这样的系统，是不是已经离0代码开发很近了？至少，我们真正实现了“只关心业务逻辑”这一初级目标。
本文从理论上说明了一个事实：为什么我们要OO。OO不是目的，OO是手段，是能够让我们实现从需求到计算机系统的高效明晰映射的有利武器。利用对业务对象和业务规则的有序分析，我们将能够据此从下而上或者从下而上（上是界面，下是数据库）分层建立映射模型，从而实现上文提及的目标系统。
接下来，将开始逐步切入实践细节：
下一篇：快速开发与0代码开发理论及实践（三）：从理论到实践----OO从下至上的统一模型：从数据库到界面
