摘要：看到一篇好文章，收藏一下我在知乎关于开发一个业务逻辑复杂的系统，应该怎么样设计才能使项目的扩展性更好做的回答。一个标准的工作流程包括业务建模，需求分析，分析设计，实施开发，测试，部署，配置和变更管理，项目管理，环境。
看到一篇好文章，收藏一下
我在知乎关于《开发一个业务逻辑复杂的系统，应该怎么样设计才能使项目的扩展性更好？》做的回答。
既然业务逻辑复杂，那意味着项目前期的业务建模、需求分析、分析设计极为重要，直接抛开这几个阶段进入技术实施开发阶段，不管套用什么设计模式、架构模式，系统的扩展性肯定难以保证。
项目的扩展性虽然最终体现为系统架构、技术实现的扩展性，但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差，大都将原因归结为技术实现烂，但总结那些成功的大型项目或产品的最佳实践，原因都会有：某某是业务专家，对xx业务很熟悉，能够衔接业务与技术。因此一个好的项目角色中，应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色，从业务架构、信息架构、技术架构保证系统的扩展性。
具体怎样进行业务建模，搭建良好的业务架构和业务模型，从而为技术架构、信息架构、技术实现奠定良好基础，有一些较为成熟的软件开发过程可供参考。例如 RUP（Rational Unified Process，统一软件开发过程)。一个标准的RUP工作流程包括：业务建模，需求分析，分析设计，实施开发，测试，部署，配置和变更管理，项目管理，环境。当然RUP只是一个方法论，且过于庞大，大部分项目很难完整执行其过程，需要根据实际情况进行裁剪，但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。
因此对于题主描述的一个复杂系统，标准的过程应当在业务建模，需求分析，分析设计，实施开发，测试，部署完整过程的分析设计（与开发语言无关）或实施开发（分析设计的成果映射为具体语言，例如Java、.NET等）阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段，类似禅修中“看山是山、看水是水”的三个阶段，才能体会模式的运用之妙。
值得强调的是：如果是偏交易（例如支付、金融）的系统，在考虑扩展性时候，一定要将信息架构、信息模型的扩展性纳入到考虑范围，此类系统数据模型至关重要，也不可能频繁变动。
上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目，对于互联网偏创新性的项目就不一定完全适用了，此类项目的现实情况如下：业务模式不确定，会不停试错，验证模式；需求不停变化，要求能够快速响应；全新的行业，没有行业专家，没有行业标杆可借鉴（至多有跨界标杆可参考）；此时候，类似精益创业、Scrum之类的敏捷开发模式更适合，但对于复杂的业务而言，业务建模->需求分析->分析设计的理念仍然值得参考借鉴。
最后，最最重要的是：完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样，中国大部分公司后任会不停否定掉前任的架构、系统，推倒再来一遍，然后等新系统刚开发出来不久，尚未上线或上线运营一段时间后，再换一帮人继续折腾，然后。。。
总结这么多年的经历，深刻体会到：再烂的系统和架构，如果能够强化管理、持续积累、持续重构、持续完善，都能够有机会成为完美的系统，完美的系统不在于其架构的牛逼和完美，而在于：符合公司的业务模式，能够完美支撑公司业务的高速发展和市场需求的快速响应。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/11704.html
摘要：而只需要调用对象完成业务逻辑即可。领域建模的好处面向对象封装的相关操作都封装在上，提高了内聚性和可重用性。对于这样简单的场景，这个建模就差不多了。这就是模型的统一。其功能性及说明性急速增强，而复杂性却随之消失。 showImg(https://segmentfault.com/img/bV62vN?w=677&h=393); 你还在用面向对象的语言写面向过程的代码吗？你是否正在被复杂的...
摘要：而只需要调用对象完成业务逻辑即可。领域建模的好处面向对象封装的相关操作都封装在上，提高了内聚性和可重用性。对于这样简单的场景，这个建模就差不多了。这就是模型的统一。其功能性及说明性急速增强，而复杂性却随之消失。 showImg(https://segmentfault.com/img/bV62vN?w=677&h=393); 云栖君导读：你还在用面向对象的语言写面向过程的代码吗？你是否...
摘要：移动精英开发社群的第期，也是围绕架构这个话题进行讨论。本次我们希望结合实际开发中遇到的问题，来聊聊移动端的架构设计。这样的模式改进一些，可能会更适合移动端架构。潘卫杰之前我们公司移动端的大项目就是插座式开发的，批量出各个行业的。 此前，58 同城的技术委员会执行主席沈剑在 OneAPM 的技术公开课上分享过一个主题，「好的架构不是设计出来的，而是演技出来的」。因为对很多创业公司而言，随...
摘要：前言本文给大家分享的题目是基于微服务以及的高可用架构探索与实现。比如说年大地震的时候我正好在东京，当时在做一个金融系统的相关工作。那次大地震导致很多很多的问题，虽然大地震不是在东京发生，但是还是给我们的系统造成了影响。 前言 本文给大家分享的题目是《基于DevOps、微服务以及K8S的高可用架构探索与实现》。整个企业的高可用架构面临很多的挑战，面向微服务、容器化以及敏态交付，是我们现在...
摘要：导言耦合性，是对模块间关联程度的度量。模块间的耦合度是指模块之间的依赖关系，包括控制关系调用关系数据传递关系。 导言： 耦合性，是对模块间关联程度的度量。耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。软件设计中通常用耦合度和内聚...
阅读 429·2021-10-09 09:57
阅读 432·2019-08-29 18:39
阅读 780·2019-08-29 12:27
阅读 2997·2019-08-26 11:38
阅读 2622·2019-08-26 11:37
阅读 1257·2019-08-26 10:59
阅读 1330·2019-08-26 10:58
阅读 957·2019-08-26 10:48
