这个问题是不可能避免的。所以我们就需要一个稳健的框架来支撑，新的需求在这个框架基础上扩展。
一个良好的架构需要满足两个重要特点：复用性，可扩展性。所以开发架构最大难点就在找到一个合理的复用点。如果复用颗粒度小，复用性就会变小，增加应用层开发复杂度；如果复用颗粒度过大，就会影响扩展性，对需求变化不利。个人认为，在不能很好把握的情况下，尽量做小，在这基础上扩展一些较大粒度的功能。当然这还需要很好设计支撑，就是选用合理的设计模式。那么架构都包括哪些层次呢？请看下图：
非领域框架层：
对于不同的领域可划分出许多类型的软件。例如销售领域，为了解决销售环节的问题，有CRM(客户关系管理)；企业资源计划，有ERP；电子商务领域，有购物网站系统。不同领域的应用系统也有公共特性。例如：配置(configuration)系统，是对应用的支持，某些应用属性，放置在配置文件里，可以很容易的更新，而不需要重新修改代码;日志系统，当软件出现异常时，希望可以通过查看日志找到问题所在，一般记录操作，异常信息等等，可以追溯。这两个模块基本是所有应用软件必须的模块，而且可以做到跟特定领域无关。当然还有其他模块，这里只是做个简单介绍。微软的Enterprise library就是为此层设计的一个解决方案，大家一定很熟悉。
此层开发者要求开发过不同领域的系统，丰富的经验，并且具有丰富的软件设计经验。
领域框架层：
特定领域有自己的共同特性。例如电子商务领域，购物系统，购物车，订单是电子商务领域共有的功能。CRM领域,客户管理是所有CRM共有的模块。将公共的功能封装，即为领域层。此层难度不亚于非领域层。因为必须懂行业知识。
此层开发者要求对业务需求有深入理解，需要有一定的行业背景，并且具有丰富的设计经验。
业务层：
这里所说的业务层，是指建立在领域框架层的业务层。当然以上两层也可以称为业务层，这里只代表部分业务层。在领域框架层的基础上，针对于不同的需求扩展不同的功能，并且为表示层提供服务。即差异性的模块放在此层，不作为底层框架。当然此层也有复用功能，但不作为此领域通用的模块，因为变化的可能性大些。此层依赖于以上框架层。
此层开发者要求对业务有一定了解，一定的设计能力。
表示层：
此层是变化最大的一层，不同的用户有不同的需求。直接使用业务层提供的服务。
此层对客户端开技能要求较高。想做一个交互能力强的软件，表示层开发者功劳不可不重视。因为也需要很多的编程知识，例如js,flex等等。
总结：
本人是以架构的视角来划分层次。可能大家会拿三层架构比较，在这里我做下简单的比较。三层架构即：数据处理层，业务逻辑层，表示层。我在这里介绍的非领域层，领域层和业务层。都可以划分为数据处理层和业务逻辑层。所以这里介绍的层次是更广义的层次。请读者能以此思路理解。
同时欢迎大家交流，互相学习。