2011年参与开发设计公司第一个称得上大型管理系统的某井工矿MES系统时，开始深入了解系统架构及程序架构，当时第一次接触到代码生成器之后，几乎大大小小的项目都会在设计完数据库后使用他快速的生成所谓的model层、bll层、dal层等，以达到快递开发的目的，以至于之后疯狂的研究了一段各种代码生成器，好处显而易见，开发容易上手，对新人和项目管理者都提供了很多正能量，但是一直对这种程序架构中的业务层（bll层）的业务处理能力产生质疑，业务层真正的完成了所谓的业务处理吗？答案肯定是没有，各种业务处理遍布在整个系统的各个角落，UI中、存储过程、视图等等。今年公司又在开发一个新的某矿业公司的MES系统，一直在断断续续的关注值.NET下MVC架构的发展，当该项目管理者XZ决定使用MVC时，突然觉得真的有人会采用具有思想的架构来完成一个具体项目了，很欣慰！但是问题依旧存在，业务层的处理怎么来做呢？依然是通过业务需求分析后，对数据库进行设计，再通过某代码生成器生成MVC架构下的代码？一直很头疼，在使用面向对象设计建模的时候，只要涉及到数据持久化好像面向对象技术总是很难真正帮助我们进行系统分析和设计。难道我们真的无法逃离表驱动的怪圈吗？真的无法将业务层完美的抽象出来吗？答案是可以的，但是完美肯定称不上。解决这个问题的方法就是应用领域驱动设计的思想，使用面向对象与领域建模技术来解决这一问题！
四色原型模式分析模式能够让我们找出业务当中的核心模型，通过核心模型具备的共性特征将其提取出来，这样将能达到业务层的高度抽象。
我们可以按照四色原型从业务需求中提取抽象类，从而画出类图。我们可以按照下面考虑顺序：
第一：它是不是依赖时间上瞬间或一段短时间存在的，是不是业务需求需要跟踪记录的对象？如果是，它就是momentinterval原型（简称MI）。
第二：然后，它是不是角色呢？如果是，就属于黄色Role原型。
第三：然后，它是不是属于一种目录式的种类性质对象，或者代表一组呢可以反复使用的概念，如果是，它就是蓝色description原型。
第四：最后，它是某人或组织？或者是某个地方或者某个东西？那它就是绿色的party, place, or thing （简称PPT）。
可以将一个复杂的系统划分成一块一块，从而有助于设计实现，当我们一个系统有好几百个类图时，如果不采取四色原型进行归类，那么无疑很混乱，甚至类图提取不正确，概念重复，甚至只有在系统代码实现时才会发现如此严重问题，这对于分析设计来说无疑时重大打击。
