首先，肯定要非常了解业务，了解客户的期望是什么！
还有一件不用假设的事实，就是变化是永恒不变的，这个不仅只针对客户的需求，还有环境（业务环境，系统环境）的变化。
其次，在以上共识的基础上，要分清楚系统的边界，以及系统中哪些组件与业务有关，哪些不与业务有关（如事务管理器，安全管理器...）。对于与业务有关的组件，哪些部分是相对于业务不变的，哪些是变的，这样作的目的是变化的部分可能就是系统用于拓展自身的点（使用接口来抽象），不变的部分可能就是通用的组件(可以放到一个通用业务层组件中，如各种业务都有的部分)，我们可以利用拓展点暴露出来的接口来动态拓展系统，就是在不改变系统现有的代码而且不需要重新编译部署的情况下拓展系统功能以便适应业务的变化。这些组件的组装可以交给反射工厂和配置文件来完成。
再其次，按排这些组件所处的层次：将与业务有关的组件放到应用层组件中，其中可以再细分两层：一层是通用业务层，一层是可以拓展的业务层。将不与业务有关的系统组件放到框架层（让他们处理诸如：事件通知，安全，事务，备份，数据访问等等等），最后将与表示（显示）有关的部分放到表现层组件中。
最后，我们根据物理的部署设计（即表现层服务器，应用服务器的设计等等），将以上组件层用RMI/Remoting/Web Service/Local的方式连接起来。
当然，在设计各层组件的时候要灵活运用设计模式，企业设计模式等等面向对象的技术。肯定的是可以使用诸如Spring.net,NHibernate
总结，不管你是用.Net还是J2EE,都可以按照上面的考虑，因为设计问题只与业务等等的因素有关，而跟使用何种技术平台无关。
还有一件不用假设的事实，就是变化是永恒不变的，这个不仅只针对客户的需求，还有环境（业务环境，系统环境）的变化。
其次，在以上共识的基础上，要分清楚系统的边界，以及系统中哪些组件与业务有关，哪些不与业务有关（如事务管理器，安全管理器...）。对于与业务有关的组件，哪些部分是相对于业务不变的，哪些是变的，这样作的目的是变化的部分可能就是系统用于拓展自身的点（使用接口来抽象），不变的部分可能就是通用的组件(可以放到一个通用业务层组件中，如各种业务都有的部分)，我们可以利用拓展点暴露出来的接口来动态拓展系统，就是在不改变系统现有的代码而且不需要重新编译部署的情况下拓展系统功能以便适应业务的变化。这些组件的组装可以交给反射工厂和配置文件来完成。
再其次，按排这些组件所处的层次：将与业务有关的组件放到应用层组件中，其中可以再细分两层：一层是通用业务层，一层是可以拓展的业务层。将不与业务有关的系统组件放到框架层（让他们处理诸如：事件通知，安全，事务，备份，数据访问等等等），最后将与表示（显示）有关的部分放到表现层组件中。
最后，我们根据物理的部署设计（即表现层服务器，应用服务器的设计等等），将以上组件层用RMI/Remoting/Web Service/Local的方式连接起来。
当然，在设计各层组件的时候要灵活运用设计模式，企业设计模式等等面向对象的技术。肯定的是可以使用诸如Spring.net,NHibernate
总结，不管你是用.Net还是J2EE,都可以按照上面的考虑，因为设计问题只与业务等等的因素有关，而跟使用何种技术平台无关。
