企业架构指导

Question

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

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

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

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

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

提前感谢您的帮助。

Answer 1

关于提供的建议： -

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

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

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

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

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

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

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