由领域驱动和MapReduce想到的

昨天看到rails类型框架的原理和思想，包括了解到RoR、Trails、Grails等基于动态语言的全栈式框架（Full-Stack）实现的开源产品，同时包括Appfuse等统一SSH企业级框架的构建出发点或者说应对现实需求的含义，再想到无论是当前软件工程、设计模式、企业级开发、计算机基础算法等的实现，无非都离不开变与不变，静与动的关系，并且随着其领域的发展，变化会转化为不变，静态会转换动态，即随着设计和开发的技术不断进步，同时用户需求不断提高，转换将是一个基本不变的原则，其过程应该是一个不断迭代发展的过程。

一、如快速排序算法的设计考虑：从一堆待排序的数据中随便选择一个数作为标准，比其大的放一边，小的放另一边，之后对两边各自进行递归重复这一过程，这其中不变的是进行分割的过程，具体体现在程序中为一个函数体的定义，变的是待排序的数据集合本身的因素包括数据集合大小（如果是向量类型则是索引的上下标）。

另外，现在大肆流行的所谓函数式编程语言，DSL（领域特定语言），个人认为归根结底还是归功于面向对象语言的发展成果，因为面向对象的特点是能够以快速应对需求的方式解决本来很繁琐、很问题，并给能够利用程序语言中的天生的接口隔离和对象封装来降低系统的耦合从而降低系统实现的难度，大部分系统应该说是面向对象实现成为事实的情况下，函数语言简练和干脆的优点立刻突显，函数式编程在实际上也是基于接口继承实现的思想，只是它背后隐藏了太多细节即用所谓规约优于配置的方法，实现了很多默认的配置，用groovy的语言来编写一个排序，一个简单的语法就搞定，不用像JAVA那些必须显示的实现一个compare接口，即去除了一些代码坏味（Bad Smell）。

二、Google提出的MapReduce框架思想，其封装分布式的实现细节，只要用户实现Map和Reduce两个方法即可，其他一切Google全给你办妥。因为Google的工程师看到，所谓分布式其实只有两件事是必须的：分割任务、归并结果，这就是整个框架中不变的东西，变的是分布式计算实现的细节，比如操作系统平台差异性屏蔽、网络通信、数据分块等。

三、领域模型驱动的提出者，他们看穿了所谓企业级开发的基础都是CRUD操作，这都是通用不变的，什么数据库缓存、ORM、底层并发和基础操作的事务控制都是通用的哥都给你封装好了，你只要照着哥的框架规范，然后干好你属于你领域的事就一切都OK了，其他的你大可视作浮云，还有比这更和谐的吗？如此一来，有了领域模型框架，你只用关注你所开发的系统中所涉及的企业需求问题或者业务逻辑，领域模型框架的建立者真是广大企业级Coder的解放者。