对项目架构做出决策；你的决策过程是怎样的？ [关闭]答案

【问题标题】：Making decisions about the architecture of your project; what is your decision process like? [closed]对项目架构做出决策；你的决策过程是怎样的？ [关闭]
【发布时间】：2009-08-12 02:04:49
【问题描述】：

我们中的许多人都是从零开始设计和开发系统的，他们都遇到过必须对项目架构做出艰难决定的情况。在构建结构合理且可扩展的系统方面，您是在哪里，或者您会在哪里划定“下一步”的界限？

我建立了一个大型网站，在架构方面相当崩溃。有一个带有前端代码的 Web 层，然后是处理要完成的实际工作的业务和数据层。不同的逻辑分离层共存于同一台物理机器上。通过使用 Web 服务层/层，可能已经存在物理分离，甚至简单的逻辑分离。由于各种原因，它没有以这种方式实施。决定是对还是错只是一个见仁见智的问题。从我的角度来看，我曾遇到过一些相对简单的应用程序被过度设计的情况。

在为新项目设计架构时，您会考虑哪些因素？您是否有经常使用的一致项目设计，您是从一开始就进行 n 层设计，还是在每个项目进入时进行评估？

反复经历这些经历，我经常想知道处于相同位置的其他人如何证明并做出这些考虑。我相信我们都会有不同的意见，但我相信理解这些意见背后的思考过程会很有启发性。

【问题讨论】：

标签： architecture scalability n-tier-architecture

【解决方案1】：

针对给定问题的正确架构完全取决于问题。您的问题太笼统，无法提供真正的答案，除了说我尽可能简单地考虑架构以考虑所有已知和预期的要求，但不会更简单。

编辑：

对于“典型”的业务解决方案，以下是我考虑的一些因素：

用户界面
- 可以基于网络吗？用户交互要求是什么？
- 如果经典 Web 界面还不够用，我可以使用 Sliverlight 等更具交互性的技术吗？
- 如果它必须是胖客户端（是的，仍有一些场景可以证明这一点），那么部署挑战有多严重？小用户群，大用户群？我需要包括自动更新吗？需要强制执行吗？
业务层
- 我是否有需要物理上独立的业务层的性能/可扩展性考虑？（我的业务层在逻辑上始终是独立的，如果需要，也很容易在物理上分离。我有时会使用 CSLA 在针对 Windows 的部署时做出决定，但这是一个繁重的框架，并不总是合适的）。
- 我的业务规则有多简单或复杂？随着时间的推移，它们可能会发生相当大的演变吗？是否值得加入 Drools 之类的规则引擎？
- 是否有异步处理要求？我需要工作队列系统吗？
- 是否有外部系统可以连接？他们提供了哪些类型的接口？ Web 服务、COM+、基于 HTTP 的 XML、专有、数据库、批处理文件，...？
数据持久性
- 考虑到任何预先存在的平台选择/限制，我可以选择哪些 ORM？
- 我会从广泛使用存储过程中受益吗？是否会有 DBA 来维护存储过程并随着时间的推移对其进行修改？如果没有 DBA，我只在性能真正需要的地方使用存储过程。如果有 DBA，更广泛地使用存储过程可以让 DBA 灵活地管理独立于应用程序的物理架构（但与所有增加的复杂性一样，这会带来成本）。
横切
- 有哪些安全要求？是否存在要集成的现有机制（Active Directory/LDAP/...）？我是否需要支持基于角色的安全性？
- 什么是操作监控要求？ “报告此错误”功能？简单的日志记录？

【讨论】：

我想我在上面已经说得很清楚了。在决定项目的架构时，我正在寻找您的决策过程。我们都知道，一种尺寸并不适合所有人，即使有些人尝试过，或者至少从这种心态开始。
我从事的项目范围如此之广，以至于在几段中写下过程是不切实际的，因为决策过程是非常非线性的（因为涉及的变量太多都相互影响）。不过，我会用一些更详细的指导原则来编辑我的答案。

【解决方案2】：

好吧，让我来告诉你——做吧。专注于您现在的任何需求，但不要试图解决所有可能的未来功能、想象中的需求变化和各种开发过程。

Joel 写了一篇很棒的文章：Don't Let Architecture Astronauts Scare You。

分析您的任何需求、您的软件需要的任何功能、查看您之前在类似项目中的经验并继续努力。

伟大的架构绝不会从第一次头脑风暴会议中诞生。你从一种方法开始，随着天气的变化调整你的路线，举行代码审查会议来产生改进架构的想法，将一些糟糕的代码片段重构为好的和可重用的组件，最后你的车库将变成一座城堡。

遵循KISS principle 并避免过早优化。

您是否有经常使用的一致项目设计？

当然。个人或团队发展自己的风格、解决典型问题的技术、可重用的组件，这些将共同构成您的工具集。为什么每次开始一个新项目时都要扔掉它们？

你从一开始就在 n 层吗？

我试着成为。它服务于一致性、清晰结构和关注点分离的目标。

或者你会在每个项目进入时进行评估

同样如此。可能有不同的方法来解决问题并以最有效的方式解决它。

【讨论】：

【解决方案3】：

在构建结构合理且可扩展的系统方面，您在哪里或将在哪里划定“下一步”的界限？

我不明白这部分问题。

在为新项目设计架构时，您会考虑哪些因素？您是否有经常使用的一致项目设计，您是从一开始就进行 n 层设计，还是在每个项目进入时进行评估？

我很幸运能够在小团队中完成几乎所有的工作，也很不幸能够在高流动率的团队中完成几乎所有工作。我学会了永远不要尝试自己构建系统；通过团队的努力，结果会更好。有时我们会进行快速原型制作，但如果团队优秀，我发现使用白板、索引卡和纸质设计可以让您走得更远。

我们确实没有有一致的项目设计；每个架构都可能是该项目的一次性架构，但我几乎只从事研究和高级开发工作。

考虑的因素：

团队是否认为架构能够完成工作？胜过所有其他考虑。
初级团队成员或新人能否轻松学习架构？其他团体会偷走你最好的人，他们会离开去创办公司。在一个案例中，我们有一个小组忙于处理现场请求而无法学习新架构，即使他们的架构阻碍了他们。
架构的结构是否反映了需要创建它的组织的结构？ :-) 有点开玩笑，但我们需要相信我们可以用我们拥有的人和时间来构建它，而不是完美的开发团队。因此，能够识别出与个人相匹配的架构部分是一件好事。
是否存在我们不理解的部分——或者更糟糕的是，是否存在我们害怕的部分？如果是这样，主要的危险信号。
漂亮吗？这是我们在午餐时与其他团队的人谈论的话题吗？如果不是，那么设计/架构可能还不够好。
是否有可识别的新想法？别人可以借鉴的东西？（这在研究环境中很重要，但我怀疑在其他地方并不重要。）

【讨论】：

【解决方案4】：

我发现预先假设性能瓶颈通常是非常糟糕的做法。您可以花费大量的前期优化，最终不会产生明显的差异。

如今，我们有一些很棒的重构工具和大量关于开发模式的资源。因为这些工具已经变得更好了，所以我在架构功能上花费的时间几乎没有以前那么多了。很粗略我的流程是这样的：

收集需求
优先考虑要求（不要在镀金功能上花费大量时间）
我通常从 2 层（UI/数据和业务逻辑）开始，除非我知道数据和业务逻辑层会预先分开。
对于每个要求，首先使其工作。这里没有模式，除非非常明显地需要它。我发现在实现中出现了对模式的需求。
工作后，清理代码，确定模式的位置并实施它们仅在需要时实现
如果需要性能，请进行性能测试，并根据需要进行重构。

如果你以这种方式工作，你会发现你犯了简单的错误。模式、第 3 方工具等在解决特定问题方面非常出色，但我想记住，每次添加类似的东西时，它都会提高以后维护应用程序所需的理解标准。所以我从简单开始，只有当它对我有所帮助时才增加复杂性。

实际上，在与其他架构师打交道时，我的口中感觉非常糟糕，他们即使对于一个小型、简单的应用程序也会使用依赖注入框架、Nhibernate、NUnit，推出他们自己的日志库，编写 3 倍的单元测试因为它们有代码行等。所有这些工具都有特定的实例，其中 ROI（投资回报率，“物有所值”）非常好，而其他情况则不是。优秀的架构师以尽可能低的时间/成本提供尽可能多的价值。

【讨论】：

【解决方案5】：

我的观察是，真正优秀的架构师会花时间深入了解已知需求，并使用相当大的判断力来了解未来的灵活性。

他们还了解层的逻辑和物理分离之间的区别。

我经常看到两种模式之一：

这适用于上一个项目，所以我们在这里使用它......即使要求不同。
以前没用，所以我们不会使用它......即使它没用的原因是实施做得不好

（如果您需要解决的唯一架构问题是解决方案中有多少层，那么您确实很幸运 :-)

【讨论】：

【解决方案6】：

我使用Spring - 它都是内置的。

【讨论】：

那么我可以在我的 iPhone 上使用 Spring 了吗？它也是嵌入式 Web 服务器的最佳选择？
PS - 只是让你很难过 ;-) 我也在一些项目中使用 Spring。
@Eric J. - 实际上，对所有人都是。我正在使用 Spring 核电站模块来运行我的后院反应堆，我听说航天飞机上的厕所有 40 万行代码，全部在 Spring 中。我要让我的妻子采用它，这样她就会更加模块化。我想更容易地交换碎片。 8)

【解决方案7】：

我最初考虑域的复杂性。如果复杂且在商业、商业或工业领域，而不是计算机或数据科学领域，我默认使用基于对象域模型的架构。

接下来我会考虑规模、重要性、期望和其他非功能性要求。

【讨论】：