看到一篇 好文章，收藏一下
我在知乎关于《 开发一个业务逻辑复杂的系统，应该怎么样设计才能使项目的扩展性更好？》做的回答。
既然业务逻辑复杂，那意味着项目前期的业务建模、需求分析、分析设计极为重要，直接抛开这几个阶段进入技术实施开发阶段，不管套用什么设计模式、架构模式，系统的扩展性肯定难以保证。
项目的扩展性虽然最终体现为系统架构、技术实现的扩展性，但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差，大都将原因归结为技术实现烂，但总结那些成功的大型项目或产品的最佳实践，原因都会有：某某是业务专家，对xx业务很熟悉，能够衔接业务与技术。因此一个好的项目角色中，应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色，从业务架构、信息架构、技术架构保证系统的扩展性。
具体怎样进行业务建模，搭建良好的业务架构和业务模型，从而为技术架构、信息架构、技术实现奠定良好基础，有一些较为成熟的软件开发过程可供参考。例如 RUP（Rational Unified Process，统一软件开发过程)。一个标准的RUP工作流程包括：业务建模，需求分析，分析设计，实施开发，测试，部署，配置和变更管理，项目管理，环境。当然RUP只是一个方法论，且过于庞大，大部分项目很难完整执行其过程，需要根据实际情况进行裁剪，但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。
因此对于题主描述的一个复杂系统，标准的过程应当在业务建模，需求分析，分析设计，实施开发，测试，部署完整过程的分析设计（与开发语言无关）或实施开发（分析设计的成果映射为具体语言，例如Java、.NET等）阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段，类似禅修中“看山是山、看水是水”的三个阶段，才能体会模式的运用之妙。
值得强调的是：如果是偏交易（例如支付、金融）的系统，在考虑扩展性时候，一定要将信息架构、信息模型的扩展性纳入到考虑范围，此类系统数据模型至关重要，也不可能频繁变动。
上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目，对于互联网偏创新性的项目就不一定完全适用了，此类项目的现实情况如下：业务模式不确定，会不停试错，验证模式；需求不停变化，要求能够快速响应；全新的行业，没有行业专家，没有行业标杆可借鉴（至多有跨界标杆可参考）；此时候，类似精益创业、Scrum之类的敏捷开发模式更适合，但对于复杂的业务而言，业务建模->需求分析->分析设计的理念仍然值得参考借鉴。
最后，最最重要的是：完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样，中国大部分公司后任会不停否定掉前任的架构、系统，推倒再来一遍，然后等新系统刚开发出来不久，尚未上线或上线运营一段时间后，再换一帮人继续折腾，然后。。。
总结这么多年的经历，深刻体会到：再烂的系统和架构，如果能够强化管理、持续积累、持续重构、持续完善，都能够有机会成为完美的系统，完美的系统不在于其架构的牛逼和完美，而在于：符合公司的业务模式，能够完美支撑公司业务的高速发展和市场需求的快速响应。