企业架构指导

Question

我们公司希望在 .net 堆栈上对整个企业的应用程序进行标准化。我们正在构建企业风格指南。我们有一位解决方案架构师帮助我们设计企业架构。他的建议包括企业服务层和具有可重用组件的企业 UI 层。

我完全同意拥有一个企业服务层，大多数（如果不是全部）Web 应用程序都将使用该层来获取数据。但是我不相信企业 UI 层。

我们现有的许多应用程序都显示相同的信息，例如订单详细信息。他的论点是，我们公司已经花钱为每个应用程序多次构建订单详细信息 UI，而它显示已构建一次并在其他应用程序中重复使用。他想在 angular 和 bootstrap 上构建可重用的 UI 组件，这些组件可以放入未来在同一堆栈上构建或重写的应用程序中。

我喜欢拥有可重用组件的想法，但我认为它应该限于结构和样式，而不包括 UI 框架。添加 UI 框架会增加每个控件的复杂性，也会增加成本，我们实际上是在构建一个 cms。除此之外，我觉得我们会被 angular 所束缚，这不一定是坏事，但如果像 React 这样的另一个框架更适合未来的应用程序呢？

我的问题是-
1. 是否有人在具有类似架构的环境中构建或工作过？您的体验如何？
2. 您认为这种架构的优缺点是什么？

在此先感谢您的帮助。

Answer 1

关于提供的建议：-

1. 企业服务层：当然，这是必要的，因为您可以统一和标准化与后端系统、数据层和第 3 方系统的接口方式。这就是我们通常所说的 Enterprise Service Bus "ESB"

2. UI 集成 不同于UI 可重用性。您可以通过多种方式使用 UI 集成

   2.1 某些框架可以为您提供工具和 API 将 运行 应用程序中的多个 UI 组件 "screens" 整合到一个屏幕中。 Microsoft 有一个 framework 和一个用于此目的的商业产品。

   2.2 Java 门户等一些技术允许您将 portlet "reusable UI components with it's business logic" 包含到任何其他门户页面中，并提供 API 以在 Portlet 之间进行通信。

3. 可重用 UI 组件当然是显而易见的，但这是开发实践并不会真正影响架构。它有自己的开销和治理，具体取决于您的项目规模。如果您有一个 UI 团队来服务所有项目，这可能会有效确保高度可重用性。

使用 ESB 绝对是最好的前进方式，但它会改变您习惯的方式。有一些地方需要考虑

1. 应用程序映射到流程，根据调查结果重新设计应用程序
2. 保护企业服务层并开发基于角色的访问控制。
3. 检查您的运营工作簿以确保在拥有企业服务层之后，您可以发现问题、隔离问题并减少对使用该服务层的其他系统的影响。
4. 服务层中的一个错误或故障会影响所有系统，因此您必须提高质量并使用 "if you are not already" 一些方法来提高质量，例如持续集成 (CI) 和完整测试自动化。
5. 您需要检查硬件并进行容量规划，以确保企业服务层运行良好并且可以扩展到足以支持所有应用程序。这里的性能测试将非常有用。企业架构师的主要任务之一是调整所有应用程序的大小并为企业服务层环境推荐规范。

Answer 2

虽然有点晚了，但我希望提供一些指导，让阅读本文的人获得最新的企业 IT 生态系统。

推荐/建议，

1. 找出贵组织的企业架构原则
2. 如果它说重用和回收，例如在你的架构设计中考虑可重用性。
3. 如果它促进创新，请退出 UI 框架标准化，因为现在每 application/service 都会被多模式应用程序消耗 例如网络、台式机、移动设备、平板电脑和设备。
4. 所以专注于构建服务层，重新表述这一层，您将其称为 SOA/API 层，使用 RPC、REST 模式开发服务，让您的 portfolios/business 开发团队发布 API/Services。对其进行分类。
5. 所以谁想在任何UI框架上开发，就让他们试验，最后在一两个UI框架上安顿下来。
6. 正如 Ahmed Hashim 所指出的，如果您需要 pub/sub 事件和编排，以及生态系统中交换数据的大量业务线应用程序，请投资 ESB。