应用开发策略选择

每个软件架构师，开发经理和开发人员都很可能遇到过软件设计和开发中“自上之下vs.自下而上”的争论。

正确的答案其实是，这里并没有单一的最佳方案。 应用是用自上而下和自下而上的两种方案之一来构建，每种方式的支持者和另一方的支持者一直争论不休。但是决定企业应该采取哪一种应用开发战略要求检视需求和资源，并且考虑到应用可能的变化，理解应用设计上这两种不同的方案以及各自减少风险的所需步骤。

模块化编程理念和企业架构都影响着软件开发，使其从上开始，从业务需求和预期收益入手。

实际上，这意味着列出业务目标，基于映射到用户行为的功能划分，用通用的软件术语来描述业务目标，然后将这些功能进一步分解，匹配硬件和软件的需求。在过去的十年里，这已经被广泛接受成为应用程序设计的最佳方法。

自上而下和自下而上

自上而下应用设计和开发也更容易和企业以及将使用应用的用户相匹配。大家理解软件做什么以及怎么做，意味着他们从应用的功能驱动视图来理解应用。如果从这样的视角开始，就可以从业务部门收集方案使用性方面的需求，并且能够洞察出业务实践随时间的改动可能会如何影响到软件设计。

这样自上而下方案的问题在于，项目目标还包括使用某种特定技术或者资源集——特别是云——的时候会遇到问题。应用不会为云自动优化；他们必须特别设计来利用云的特定特性，同时避免花费过多。从上开始的话，架构师可能能够构造出一些和一开始的目标平台以及托管选项不是特别匹配的东西。自下而上的方案才能够确保托管以及资源的正确使用。

自下而上的应用开发战略更容易契合通过面向服务架构或者微服务的使用而开发的组件库。如果可以从已有软件组件组装出一个应用程序——或者其中的一大部分——那么就可以减轻开发负担和应用生命周期管理需求。自上而下方案在现有组件模型没有什么用时可以领导设计的方向。

方案之争
经验丰富的开发团队已经适应了自上而下vs自下而上的应用开发战略之争，但是有两种基础方案得到了广泛认可。一种着重考虑资源或者平台目标，认为这些和功能需求一样重要，另一种更像是“在中间会和”的方案。

很容易看出，如果需要为使用现有模块化模型而进行优化，或者为云计算做准备，这样的需要提升成为需求时，那么应用程序设计需要从一开始就考虑到这些需求，并且按需作出设计。但是，不是所有开发团队都能够轻松在设计的最高层混合功能和技术的需求。使用云技术如何和支持某种特定的功能行为相契合呢？如果无法回答这个问题，那么流行的做法是设置某个需求集的优先级高于另一个需求集。这样能够完成拥有有限功能的设计。

当基于资源，平台或者组件重用的目标，业务需求适合某个假定的应用模型时，“提升”模型能够工作得很好。比如，一个基本的Web前端软件模型，管理特定的系统-用户关系，链接到一系列解决企业功能需要的应用流程上，能够足够好地组织开发工作，确保重用需求可见，而不牺牲任何功能性。

“在中间会和”方案假定平台和组件创建一个能够抽象到一系列技术行为的工具包。比如，可用组件能够组装起来更新数据库或者完成报告。这些高层级的行为也能够关联到云特性上，比如水平扩展或者故障发生时的实例置换。虽然它们可能无法直接映射到新应用的功能性需求——或者它们可能对于项目而言并不需要——它们比基础技术需求更加功能化。架构师随后就能够基于这些行为组合出第二或者第三层设计。

基于行为，在中间会和的应用开发战略的问题是，如何向上反应行为感知性，而不会被底层问题占据。最佳方式是从底层开始组装有用的行为，然后将其暴露成工具给架构师，架构师从顶层开始功能性设计。该方案在有显式高层功能性需求时最有用，这些需求可能来自一个良好的EA模型。没有非常强有力的功能性需求，那么设计流程就很容易被自下而上的资源探求和组件战略所占据。

底线
自上而下的设计很好地将应用和业务目标契合在一起，并且优化用户体验的质量，但是他们可能创建出不是最优的组件化，并且限制了应用程序采纳新技术，比如云计算的能力。自下而上的设计优化资源和组件化能力，但是可能会偏离用户的体验质量。最后，最好选择契合你的最重要目标的方案，然后一步步确保能够兼顾到另一端。

本文转自d1net（转载）