请教各位如何应对快速变化的需求？
1。建立一个卡类型管理画面，把所以信息保存到数据库，即使将来还有新卡类型也只是增加记录，但是banq大哥好象很不主张以数据库为基准的设计，呵
2。在项目中编写卡的接口或者是抽象类，将来有了新卡类型用反射获取相关信息
但个人觉得有点麻烦，是不是将来联通新增一个卡类型，就又要我们开发公司帮忙开发一个新的子类插入系统中，虽然可能不需要重新编译整个项目，但是还是觉得不方便，是不是我认识有误，用反射做开发不是这样的？
1。建立一个卡类型管理画面，把所以信息保存到数据库，即使将来还有新卡类型也只是增加记录，但是banq大哥好象很不主张以数据库为基准的设计，呵
2。在项目中编写卡的接口或者是抽象类，将来有了新卡类型用反射获取相关信息
但个人觉得有点麻烦，是不是将来联通新增一个卡类型，就又要我们开发公司帮忙开发一个新的子类插入系统中，虽然可能不需要重新编译整个项目，但是还是觉得不方便，是不是我认识有误，用反射做开发不是这样的？
做设计的时候要做成本的分析，怎样避免最困难的事情
跟用不用数据库没有任何的关系
如果方法一的维护成本低于方法二的维护成本就应该选择方法一
反之亦然。
没有绝对的设计，也没有一成不变完美的设计
用户需求的变化是必然的
但是如果你做软件的时候始终站在用户的角度而不是自己的角度
设计起来就得心应手了
资费(ID,fk_cardid,起始日期,结束日期,收费标准....)
card 1--------->n 资费
不知道是不是需求只是你说的那一点，还是已经有了现有框架需要增加这个功能
如果有了现有的框架，那么你基本不需要想什么，添上代码就好了
如果是自己新建的，那我就想问问你要查这些卡，目的是什么？？
为了展示？？为了计费？？还是只是一个中间变量类型？？
如果查询是最终目的，可以设计的很简单，三层结构访问就可以了
计费的话2层结构就够了，一个简单的软件就可以了
如果是中间变量类型那就需要重新定位它在系统中的位置了。
我个人认为是这样，业务模型变化，必然带来代码更新，不能幻想机器人帮助我们来完成业务代码。象你试图通过数据库记录变化，替代业务变化，这可能在一定情况下有效，但只能是一个临时之计，业务代码也会要修改的。
我们可以通过好的设计降低代码更新量，比如四色模型设计中，我们可以设计一个卡类，用来描述卡的一般属性通用特性，概时，需求变化时，只要实现特殊部分就可以，比如如意卡的特殊之处，围绕特殊之处实现一些功能添加修改。
采取OO，只是比以前更快更方便应对需求变化，而且，不会担心一旦修改，牵一动百的影响，系统只是比以前健壮。
如果还希望更快，通过MDA这些工具，UML图改了，代码就出来了...当然目前不是非常成熟。
也想知道怎么不通过编译源代码和数据库怎么加入新的卡类型
希望banq不吝赐教
详细说明
http://www.jdon.com/mda/archetypes.html
四色原型一般在MDA中起初使用，是对需求的一种科学分析方法。
它与领域模型区别是：
Evans DDD是一种MDD，比MDA/DSL/DSM自动化程度差一步，是现今我们普遍采取的方式。四色原型比领域模型更抽象，原始。
受益匪浅
不过有一些不明白的地方
比如说你需要添加一种新的role
如何动态的添加而不需要编译源代码或者添加数据？？