实际案例
最近接手一个任务系统，后台配置满满一篇的任务相关属性，包括了名称、类型等固定字段和各种各样可选的达成条件。数据模型的设计也就和试图模型一样，有很多字段，估计是长期不断加需求慢慢演变成这样的结果。
现在面临的问题是做任何改动逻辑都很复杂，所有的逻辑都是在分析同一个模型的各种字段。
糟糕的设计
需求是怎么样就数据模型和视图模型就都设计成什么样，不断的增加数据字段。
弹性设计
重要原则是：尽量保证数据模型的精简和视图模型的完整。也就是说，数据模型和视图模型是可以完全不同的，仔细分析需求，将固定属性项放到数据模型中，类似的可选项抽象成另一个数据模型。
实际案例改造
本例中，可以将达成任务的条件抽象出来，另外建一个数据模型，数据库存取和逻辑处理都用这个模型，要给视图时再转为视图模型。
