在谈到不会轻易改变的架构上的决定时，并不限于该设计相关的决定是不可逆的和今后变化的成本会相当的高这两种。不会轻易改变的决定无处不在，从某一层的设计到某个类的属性都有可能。

1，修改业务逻辑的组织方式
业务逻辑的组织方式大概可以分下面四种：
1）事物脚本模式
2）表模块模式
3）活动记录模式
4）领域模型模式
选择业务逻辑模式就是一个需要异常仔细考虑的决定，一旦确定下来，再要修改其它的模式，将会非常的麻烦，会在很大程度上影响到数据访问层和应用层（服务层），甚至还会影响到表现层。若需要在项目中推翻该决定，难免会造成整个系统层面的重构。

2，改用另一个类库
比如你已经基于某个特定的类库开发了一些功能（比如使用了一个富文本控制），而有一天领导要求你不能使用该类库。这时，我们就不得不处理一个意料之外的非功能的需求。

需求上的一个修改也许会使架构也随之调整，不过带来的成本又如何呢？这时，我们一般都要尽力满足新的需求，因为不会有商量的余地。

在最好的情况下，你也许可以找到一个类似的，差不多的类库来代替，否则，就要考虑是否修改原有的架构，从而让系统不再需要使用该类库。

我们最近就遇到了一个类似的问题，这个类库是一个对象/关系映射工具。如果一个UI控件类库，那么处理起来可能就相对的简单，但使用另一个对象/关系映射工具却不是那么的容易，只能考虑使用另一个类似功能的工具。

3，修改构造函数的签名
不要以为架构关注的都是一些高层次的决定，例如，上面那些会影响到中间层设计和实现的地方，哪怕是修改构造函数签名这亲的一个问题都有可能让你陷入泥潭。

例如，应用程序的对象模型中维护着一个Order类。同时你也没有使用工厂来创建这个Order类的实例。这些在项目中的各个地方可能都充斥着类似于new Order()代码，但你没有发现这个Order类和某个类型(例如Customer)有着依赖。突然有一天，某个需要要求Order类必须与Customer类一同创建，那么此时又该怎么做呢？

若是仅仅为Order新增一个新的构造函数，接受一个Customer作为参数显然没有满足需求，因为Order的原有构造函数仍旧可以使用，如果删除原来的Order构造函数，又不得不修改原来大量的new Order语句。但如果原来已经为Order类定义了工厂，那么满足新的需求就变的非常简单了（需要提醒的，领域驱动设计是理论实际上建议总是使用工厂来创建复杂对象）。

4，修改成员的修饰符
在设计类型时，需要决定类型是public的还是internal的，以及类型是sealed的还是可以被继承的，最后要决定各个方法是不是需要virtual。若是误用了virtual或sealed修饰符，也许会让设计变的非常的丑陋。

一般来说，使用virtual和sealed修饰符需要承担不少的责任。在C#中，默认情况下类型均是非密封非virtual的。而在java中，方法默认是virtual的。对于.net类型又该如何做呢？

从设计的角度考虑，密封类看起来非常的完美。实际上，如果类型一开始就被声明为密封，那么即使已经基于该类型编写了程序，日后改为非密封的也很简单，同时也不会带来什么不兼容的地方。Virtual方法也是如此，这个规律也可以运用到类型及类型成员的可见性上，即默认为private，如果相反处理，就不是那么容易了。

但如果从测试角度考虑，非密封类和virtual方法会大大方便测试。不过能够有何种程度上的方便取决于使用的测试工具。例如，TypeMock这个测试工具就不会受到这个限制。因此我们很难针对sealed和virtual关键字给出一个明确的使用建议。

(本文摘自：Microsoft.NET 企业级应用架构设计)F