对项目的架构进行决策;您的决策过程是什么样的?

给定问题的正确架构完全取决于问题。你的问题太笼统了,无法给出一个真正的答案,而不是说我尽可能地保持架构的简单,以考虑所有已知的和预期的需求,但并不简单。

编辑:

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

• 用户界面

  • 它能基于网络吗?什么是用户交互要求?
  • 如果一个经典的Web界面不够,我可以使用更交互式的技术,比如sliverlight吗?
  • 如果必须是厚客户机(是的,仍然存在这样的场景),那么部署挑战有多严重?用户基数小,用户基数大?我需要包括自动更新吗?需要强制执行吗?

• 业务层

  • 我是否需要一个物理上独立的业务层来考虑性能/可伸缩性?(我的业务层总是逻辑上分离的,如果需要,也很容易物理上分离。我有时用 CSLA 考虑到部署时针对Windows的决定,但这是一个很重的框架,并不总是合适的)。
  • 我的业务规则有多简单或复杂?它们是否可能随着时间的推移而发生相当大的变化?是否值得加入规则引擎,例如 Drools ?
  • 是否有异步处理要求?我需要工作队列系统吗?
  • 是否有外部系统与之接口?它们提供哪些类型的接口?Web服务、COM+、XML over HTTP、专有、数据库、批处理文件…?

• 数据持久层

  • 考虑到任何预先存在的平台选择/约束,我可以选择哪些ORM?
  • 广泛使用存储过程会使我受益吗?是否有DBA来维护存储过程并随时间修改它们?如果没有DBA,我只在性能真正需要的地方使用存储过程。如果存在DBA,则更广泛地使用存储过程使DBA能够灵活地管理独立于应用程序的物理体系结构(但与所有增加的复杂性一样,这也会带来成本)。

• 横切

  • 安全要求是什么?是否存在要与之集成的现有机制(Active Directory/LDAP/…)?我需要支持基于角色的安全吗?
  • 操作监控要求是什么?”报告此Bug的功能?简单测井?

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

乔尔写了一篇很棒的文章: Don't Let Architecture Astronauts Scare You .

分析您拥有的任何需求,您的软件需要的任何特性,看看您以前在类似项目中的经验,然后开始它。

一个伟大的建筑永远不会从第一次脑风暴中诞生。你从一个方法开始,随着天气的变化调整你的路线,进行代码审查会议,这些会议将产生改进体系结构的想法,将一些不好的代码片段重构成好的和可重用的组件,最后你的车库将变成一座城堡。

跟随 KISS principle 避免过早优化。

你经常使用的项目设计是否一致?

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

你从一开始就是N层的吗?

我试着去做。它服务于一致性、干净结构和关注点分离的目标。

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

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

在构建一个结构良好且可扩展的系统的“下一步”上,您在哪里,或者您会在哪里划出界限?

我不明白这部分问题。

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

我很幸运,几乎所有的工作都是在小团队中完成的,而不幸的是,几乎所有的工作都是在高营业额的团队中完成的。我学会了 永远不要试图独自构建一个系统 ;团队合作的结果更好。有时我们已经完成了快速原型设计,但是如果团队表现出色,我发现您可以用白板、索引卡和纸设计实现令人惊讶的目标。

我们肯定会的 不 有一个一致的项目设计;每个架构可能是项目的一次性,但我几乎只在研究和高级开发中工作。

考虑因素:

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

2. 初级团队成员或新成员可以很容易地学习体系结构吗?其他团体会偷走你最好的人,他们会离开创办公司。在一个案例中,我们有一个团队,他们忙于处理字段请求,以至于无法学习新的体系结构,即使他们所拥有的体系结构阻碍了他们。

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

4. 有没有我们不明白的地方,或者更糟的地方,有没有我们害怕的地方?如果是,主要的危险信号。

5. 它漂亮吗?午餐时我们会很自豪地和其他团队的人讨论这件事吗?如果没有,设计/架构可能还不够好。

6. 是否有可识别的新想法?其他人可以从中学到什么?(这在研究环境中很重要,但我怀疑在其他地方并不重要。)

我发现预先假设性能瓶颈通常是非常糟糕的做法。你可以花费大量的前期优化,最终没有明显的区别。

现在我们有一些很好的重构工具和很多关于开发模式的资源。因为这些工具已经变得更好了,所以我没有像以前那样花太多时间在架构功能上。我的流程大致如下:

1. 收集需求
2. 优先考虑需求(不要在镀金功能上花费太多时间)
3. 我通常从2层(UI/数据和业务逻辑)开始,除非我知道数据和业务逻辑层将预先分离。
4. 对于每一项要求,首先要使其生效。这里没有模式,除非它是痛苦明显的需要。我发现在实现中出现了对模式的需求。
5. 在它工作之后,清理代码,识别模式的位置并实现它们。 只有在你需要的时候
6. 如果性能是一项需求,请进行性能测试,并根据需要进行重构。

如果你以这种方式工作,你会发现你犯了简单的错误。模式、第三方工具等在解决特定问题方面非常棒,但我想记住,每次添加类似的内容时,都会提高以后维护应用程序所需的理解水平。所以我开始时很简单,只有当它特别为我带来一些东西时才会增加复杂性。

当我与其他架构师打交道时,我实际上尝到了一种相当糟糕的滋味,这些架构师即使是一个小的、简单的应用程序,也会接触到依赖注入框架、nhibernate、nunit、滚动自己的日志库、编写3倍多的单元测试(因为它们有代码行)等。所有这些工具都有特定的实例,其中ROI(返回在投资方面,“一掷千金”是非常好的,而在其他情况下则不然。一个好的架构师以尽可能低的时间/成本提供尽可能多的价值。

我的观察是,真正优秀的架构师需要花时间深入理解已知的需求,并在理解未来灵活性的提供方面运用相当大的判断。

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

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

• 这对上一个项目有效,所以我们在这里使用它…即使要求不同。
• 以前没用过,所以我们不会用它…尽管它不起作用的原因是实施工作做得不好

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

我用 Spring -都是内置的。

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

接下来,我将考虑规模、关键性、期望和其他非功能性需求。