Kru*_*nal 3 architecture design-patterns software-design
关于基于在线Web的软件应用程序,我们在决定产品开发方法时面临困难.
我们正在开发有可能作为SAAS服务提供的在线Web应用程序的系统设计.我们在决定以下系统设计和实施相关决策方面遇到了困难,也有很多成本考虑.
方法A:
我们设计和开发所有内容以考虑满足基本要求的非常基本的要求,并解决手头的问题并启动它.一个足够好的系统,可以支持几百个用户,而不必过多地关注微优化一切.
我们通过添加新模块在客户端请求时添加新功能.
因此,简单的设计,单一的开发,在必要时通过升级基础设施或在需要时进行优化来扩展,并且可能在将来需要的全新系统替换系统.
我们保留相同的服务器,但客户帐户的数据库不同.同样,为每个客户端托管不同的应用程序访问单独的数据库等.当需要时,我们可能会添加新服务器.虽然很难管理/维护和升级.
方法B:
我们研究了完整的要求,可能添加的功能可能会增加额外的价值(尽管我们仍然不确定哪些附加功能会增加多少价值？)并设计支持大量用户的系统(具有大量硬件) ) 从开始.
我们推出功能齐全的应用程序,从一开始就进行了非常好的优化.
我们将其设计为支持单个数据库和应用程序托管中的多个客户帐户,并在云服务器/负载平衡服务器上实现它,其架构就像成熟的SAAS应用程序.虽然这使得编码和维护变得非常困难.绝对需要更多时间来实施.
注意,
我们准备了我们可能正在使用的功能列表,UI和可能的技术设置.我想了解解决这种情况的最佳方法.
正如我之前看到的另一个产品开发项目那样,通过所有功能的集合,它需要很长时间才能完成,甚至它具有根本没有被使用的这些功能.这些项目的成本考虑非常高,我更倾向于采用方法A,因为这是快速,简单和可预测的.此外,与第二种方法相比,我很快就会收到用户反馈,这可能有助于我决定要关注哪些功能以及原因.此外,当需要时,我们可能会重写整个应用程序,重点关注类似于方法B的系统.
我想了解其他公司如何处理这种情况,以及实施此类项目的最佳方式是什么？
这是经典Big Design Up Front(BDUF)辩论的新版本:我们的设计是否应该在实施之前完成并完善,还是我们应该逐步设计？
我见过亲BDUF和反BDUF相当不错的论据.就个人而言,我更喜欢中间点:有必要做一些前期设计 - 否则你的设计会通过迭代进行彻底改变 - 但这个阶段不应该花太长时间,否则你只会有一个架构文档和无聊的程序员经过数月的工作.
所以,我会用方法B做一些方法A.