企业架构指导

Question

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

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

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

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

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

提前感谢您的帮助。

Answer 1

关于提供的建议：-

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

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

   2.1 一些框架可以为您提供工具和 API，以将多个 UI 组件“屏幕”从正在运行的应用程序集中到一个屏幕中。 Microsoft 有一个framework 和用于此目的的商业产品。

   2.2 Java 门户等一些技术允许您将“可重用 UI 组件及其业务逻辑”包含到任何其他门户页面中，并提供 API 以在 Portlet 之间进行通信。

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

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

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

Answer 2

虽然有点晚了，但我希望提供一些指导，以便阅读本文的人能够从企业 IT 生态系统中获得最新信息。

建议/建议，

1. 找出贵组织的企业架构原则
2. 例如，如果它说重用和回收，请在架构设计中考虑可重用性。
3. 如果它促进创新，请退出 UI 框架标准化，因为现在多模式应用程序消耗的每个应用程序/服务 例如网络、桌面、移动设备、平板电脑和设备。
4. 因此，专注于构建服务层，重新表述这一层，您将其称为 SOA/API 层，使用 RPC、REST 模式开发服务，让您的投资组合/业务开发团队发布 API/服务.将其编入目录。
5. 因此，无论谁想要在任何 UI 框架中进行开发，都可以让他们进行试验，最终选择一两个 UI 框架。
6. 正如 Ahmed Hashim 所指出的，如果您需要发布/订阅事件和编排，以及生态系统中用于交换数据的大量业务线应用程序，请务必投资 ESB。