制定有关项目架构的决策;你的决策过程是什么样的？

Question

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

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

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

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

Answer 1

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

编辑：

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

• UI

  • 可以基于网络吗？用户交互要求是什么？
  • 如果经典的网络界面不够用，我可以使用更具互动性的技术，例如Sliverlight吗？
  • 如果必须是胖客户端（是的，仍然存在合理的情况），部署挑战有多严重？用户群小，用户群大？我是否需要包含自动更新？是否需要强制执行？

• 业务层

  • 我是否需要具有物理上独立的业务层的性能/可伸缩性注意事项？ （我的业务层始终在逻辑上是分开的，并且在需要时可以轻松地进行物理分离。我有时会使用CSLA在部署时针对Windows进行该决策，但这是一个繁重的框架，并不总是合适的。 / LI>
  • 我的业务规则有多简单或复杂？他们可能会随着时间的推移而发展很大吗？是否值得合并规则引擎，例如Drools？
  • 是否有异步处理要求？我是否需要工作队列系统？
  • 是否有外部系统与之接口？它们提供什么类型的接口？ Web服务，COM +，HTTP上的XML，专有，数据库，批处理文件，......？

• 数据持久性

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

• 交叉切割

  • 有哪些安全要求？是否存在要与之集成的现有机制（Active Directory / LDAP / ...）？我是否需要支持基于角色的安全性？
  • 什么是运营监控要求？ “报告此错误”功能？简单的记录？

Answer 2

好吧，让我成为那个告诉你的人 - 干脆做吧。专注于你现在的任何要求，但不要试图解决所有可能的未来特征，想象的需求变化和各种发展过程。

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

分析您拥有的任何要求，无论您的软件需要什么功能，请查看您以前使用类似项目的经验并继续使用。

伟大的建筑从来没有出现在第一次脑力激荡会议之外。您可以从一种方法开始，随着天气变化调整您的课程，进行代码审查会议，以产生改进架构的想法，将一些不良代码重构为优质和可重复使用的组件，最后您的车库将变成一座城堡。 / p>

关注KISS principle并避免过早优化。

  

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

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

  

你从一开始就是n级吗？

我努力做到。它服务于一致性，清洁结构和关注点分离的目标。

  

或者您是否评估每个项目的进展情况

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

Answer 3

  

在构建体系结构合理且可扩展的系统时，您或者您是否会在“下一步”中划清界限？

我不明白这部分问题。

  

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

我很幸运能够在小团队中完成几乎所有的工作，不幸的是，几乎所有的工作都在高流动率的团队中完成。我已经学会了从不尝试自己构建一个系统;团队合作的结果更好。有时候我们已经完成了快速原型制作，但如果团队很好，我发现你可以用白板，索引卡和纸张设计获得惊人的效果。

我们肯定不拥有一致的项目设计;每个架构都可能是项目的一次性 - 但我几乎专门从事研究和高级开发。

考虑的因素：

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

2. 初级团队成员或新人可以轻松学习架构吗？其他团体会窃取你最好的人，他们会离开去创办公司。在一个案例中，我们有一个团队，他们太忙于为现场请求学习新架构，即使他们所拥有的架构正在阻止它们。

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

4. 是否存在我们不理解的部分 - 或者更糟糕的是，我们害怕哪些部分？如果是这样，主要的危险信号。

5. 漂亮吗？在与其他团队的人共进午餐时，我们会为此感到自豪吗？如果没有，设计/架构可能还不够好。

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

Answer 4

我发现预先考虑性能瓶颈通常是非常糟糕的做法。您可以花费大量的前期优化，最终没有明显的差异。

我们现在有一些很棒的重构工具和很多关于开发模式的资源。因为工具已经变得更好了，所以我不会花费与架构功能相同的时间。非常粗略我的过程是这样的：

1. 收集要求
2. 优先考虑要求（不要花很多时间在镀金功能上）
3. 我通常从2层（UI /数据和商业逻辑）开始，除非我知道数据＆amp;业务逻辑层将在前面分开。
4. 对于每个要求，首先使其工作。这里没有模式，除非它显然需要它。我发现在实施过程中出现了对模式的需求。
5. 工作完成后，清理代码，识别模式的位置并仅在需要时实现
6. 如果要求性能，请进行性能测试，必要时进行重构。

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

在与其他建筑师打交道时，我的嘴巴确实很不好，即使是一个小的，简单的应用程序也会达到依赖注入框架，Nhibernate，NUnit，滚动他们自己的日志库，编写3x单元测试因为他们有代码行等等。所有这些工具都有特定的例子，投资回报率（投资回报率，“砰然一声”）非常好，而其他情况则不然。一个优秀的架构师可以尽可能以最低的时间/成本提供尽可能多的价值。

Answer 5

我的观察是，真正优秀的建筑师会花时间深入了解已知的要求，并在理解未来的灵活性提供方面使用相当大的判断力。

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

我常常看到两种模式中的一种：

• 这适用于上一个项目，所以我们在这里使用它......即使要求不同。
• 之前没有用，所以我们不会使用它......即使它不起作用的原因是这项工作很糟糕

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

Answer 6

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

Answer 7

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

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