architecture - 对项目的架构做出决定;你的决策过程是怎样的?

标签 architecture scalability n-tier-architecture

<分区>

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

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

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

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

最佳答案

给定问题的正确架构完全取决于问题本身。您的问题过于笼统,无法提供真正的答案,只能说我尽可能保持架构简单,以说明所有已知和预期的要求,但不能更简单。

编辑:

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

  • 界面

    • 它可以基于网络吗?用户交互要求是什么?
    • 如果经典的网络界面不够用,我可以使用 Sliverlight 等交互性更强的技术吗?
    • 如果它必须是胖客户端(是的,仍然有一些场景可以证明这一点),那么部署挑战有多严重?小用户群,大用户群?我需要包括自动更新吗?是否需要强制执行?
  • 业务层

    • 出于性能/可扩展性的考虑,我是否需要物理上独立的业务层? (我的业务层在逻辑上总是分开的,如果需要的话也很容易在物理上分开。我有时会使用 CSLA 来允许在针对 Windows 的部署时做出该决定,但这是一个沉重的框架,并不总是合适的)。
    • 我的业务规则有多简单或多复杂?随着时间的推移,它们可能会发生很大的变化吗?是否值得合并规则引擎,例如 Drools
    • 是否有异步处理要求?我需要工作队列系统吗?
    • 是否有可以连接的外部系统?他们提供什么类型的接口(interface)? Web 服务、COM+、HTTP 上的 XML、专有的、数据库、批处理文件……?
  • 数据持久化

    • 考虑到任何预先存在的平台选择/约束,我可以选择哪些 ORM?
    • 大量使用存储过程对我有好处吗?是否会有 DBA 来维护存储过程并随着时间的推移修改它们?如果没有 DBA,我只会在真正需要性能的地方使用存储过程。如果有 DBA,更广泛地使用存储过程可以让 DBA 灵活地管理独立于应用程序的物理架构(但随着所有增加的复杂性,这会带来成本)。
  • 交叉领域

    • 安全要求是什么?是否存在要集成的现有机制(Active Directory/LDAP/...)?我需要支持基于角色的安全性吗?
    • 运营监控要求是什么? “报告此错误”功能?简单的日志记录?

关于architecture - 对项目的架构做出决定;你的决策过程是怎样的?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1263886/

相关文章:

c# - 我应该在 n 层应用程序中测试哪一层

java - 寻求意见 : architectural blueprints for instance level security

Android 应用程序级范围变量

asp.net-mvc - 洋葱架构 - 在哪里放置复杂的数据库查询查找

java - 如何在 java 中生成一个大的(30MB+)xml 文件?

ruby-on-rails - 如何使用 Rails 进行扩展

architecture - 在分层项目中放置依赖注入(inject)相关代码的最佳层

c# - 抽象掉 Main 的框架

python - 由 pywin32 生成的 python 可执行文件中的 dll 加载错误

python - 在需要可扩展的 Python Web 应用程序中解开大量数据是否可行?