2

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

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

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

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

4

7 回答 7

3

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

编辑：

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

  • 用户界面

    • 它可以基于网络吗？用户交互要求是什么？
    • 如果一个经典的网页界面还不够，我可以使用像 Sliverlight 这样更具交互性的技术吗？
    • 如果它必须是胖客户端（是的，仍有一些场景可以证明这一点），那么部署挑战有多严重？小用户群，大用户群？我需要包括自动更新吗？是否需要强制执行？

  • 业务层

    • 我是否有需要物理上独立的业务层的性能/可扩展性考虑？（我的业务层在逻辑上总是分开的，如果需要的话也很容易在物理上分开。我有时使用CSLA来允许在针对 Windows 的部署时做出该决定，但这是一个沉重的框架，并不总是合适的）。
    • 我的业务规则有多简单或多复杂？随着时间的推移，它们可能会发生相当大的演变吗？是否值得加入诸如Drools之类的规则引擎？
    • 有异步处理要求吗？我需要工作队列系统吗？
    • 是否有外部系统可以与之交互？他们提供了哪些类型的接口？Web 服务、COM+、基于 HTTP 的 XML、专有、数据库、批处理文件，...？

  • 数据持久性

    • 考虑到任何预先存在的平台选择/约束，我可以选择哪些 ORM？
    • 我会从广泛使用存储过程中受益吗？是否会有 DBA 来维护存储过程并随着时间的推移对其进行修改？如果没有 DBA，我只在性能真正需要的地方使用存储过程。如果有 DBA，更广泛地使用存储过程使 DBA 可以灵活地管理独立于应用程序的物理架构（但与所有增加的复杂性一样，这会带来成本）。

  • 横切

    • 有哪些安全要求？是否存在要集成的现有机制（Active Directory/LDAP/...）？我是否需要支持基于角色的安全性？
    • 运行监控的要求是什么？“报告此错误”功能？简单的日志记录？
于 2009-08-12T02:07:18.883 回答
2

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

Joel 写了一篇很棒的文章：不要让建筑宇航员吓到你。

分析你有什么需求，你的软件需要什么功能，看看你以前在类似项目中的经验，然后去做。

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

遵循KISS 原则，避免过早优化。

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

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

你从一开始就是n层吗？

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

还是您在每个项目进入时进行评估

那也是。可能有不同的方法来解决问题并以最有效的方式解决它。

于 2009-08-12T12:34:22.790 回答
1

你在哪里，或者你会在哪里划定界限，以建立一个架构合理且可扩展的系统的“下一步”？

我不明白这部分问题。

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

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

我们绝对没有一致的项目设计；每个架构对于项目来说都是一次性的——但我几乎只从事研究和高级开发工作。

考虑的因素：

  1. 团队是否认为架构能够完成工作？胜过所有其他考虑。

  2. 初级团队成员或新人能否轻松学习架构？其他团体会偷走你最好的人，他们会离开去创办公司。在一个案例中，我们有一个小组忙于处理现场请求而无法学习新架构，即使他们所拥有的架构阻碍了他们。

  3. 架构的结构是否反映了需要创建它的组织的结构？:-) 有点开玩笑，但我们需要相信我们可以用我们拥有的人和时间来构建它，而不是完美的开发团队。因此，能够识别与个人匹配的架构部分是一件好事。

  4. 有没有我们不理解的部分——或者更糟糕的是，有没有我们害怕的部分？如果是这样，主要的危险信号。

  5. 漂亮吗？这是我们在午餐时与其他团队的人谈论的话题吗？如果不是，那么设计/架构可能还不够好。

  6. 是否有可识别的新想法？别人可以借鉴的东西？（这在研究环境中很重要，但我怀疑在其他地方并不重要。）

于 2009-08-12T03:23:26.430 回答
1

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

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

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

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

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

于 2009-08-12T04:23:44.390 回答
1

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

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

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

  • 这适用于最后一个项目，所以我们在这里使用它......即使要求不同。
  • 那以前不起作用，所以我们不会使用它……即使它不起作用的原因是实施做得不好

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

于 2009-08-12T12:19:11.703 回答
0

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

于 2009-08-12T02:06:09.163 回答
0

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

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

于 2016-04-14T13:32:11.737 回答