我们公司希望在.net堆栈上对整个企业的应用程序进行标准化。我们正在构建一个企业风格的指南。我们有一位解决方案架构师帮助我们设计企业架构。他的建议包括一个企业服务层，以及一个具有可重用组件的企业UI层。
我完全同意拥有一个企业服务层，即使不是所有的网络应用程序也会使用它来获取数据。然而，我对企业UI层并不信服。
我们现有的许多应用程序显示相同的信息，例如订单详细信息。他的论点是，我们公司已经为每个应用程序多次构建订单详细信息UI，因为它显示已经构建了一次并在其他应用程序中重用。他希望在angular和bootstrap上构建可重用的UI组件，这些组件可以被放入在同一堆栈上构建或重写的未来应用程序中。
我喜欢拥有可重用组件的想法，但我认为它应该局限于结构和样式，而不包括UI框架。添加UI框架会增加每个控件的复杂性，成本也会更高，我们实际上是在构建一个cms。除此之外，我觉得我们会被angular所束缚，这并不一定很糟糕，但如果像react这样的另一个框架更适合未来的应用程序呢？
我的问题是-
1.有人在类似的建筑环境中建造或工作过吗？你的经历是什么
2.你认为这种架构的优点和缺点是什么？
提前感谢您的帮助。
关于提供的建议：-
- 企业服务层：这当然是必要的，您可以统一和标准化与后端系统、数据层和第三方系统的接口方式。这就是我们通常所说的企业服务总线"ESB"
-
UI集成与UI可重用性不同。可以通过多种方式使用UI集成
2.1一些框架可以为您提供工具和API，将运行应用程序的几个UI组件"屏幕"整合到一个屏幕中。为此，微软有一个框架和一个商业产品。
2.2 Java Portals等一些技术允许您将Portlet"具有业务逻辑的可重用UI组件"包含到任何其他门户页面中，并提供API在Portlet之间进行通信。
-
可重用UI组件当然是显而易见的，但这是一种开发实践，并没有真正影响体系结构。它有自己的开销和治理，这取决于您的项目规模。如果您有一个UI团队来为所有项目提供服务，这可能会有效地确保高可用性。
使用ESB肯定是最好的方法，但它会改变你习惯的方式
- 应用程序映射到流程，根据发现重新设计应用程序
- 保护企业服务层并开发基于角色的访问控制
- 查看您的操作工作簿，以确保在拥有企业服务层后，您可以识别问题，隔离问题，并减少对使用服务层的其他系统的影响
- 服务层中的一个错误或故障将影响所有系统，因此您必须提高质量，并使用"如果您还没有"一些方法来提高质量，如具有完全测试自动化的连续集成（CI）
- 您需要检查硬件并进行容量规划，以确保企业服务层性能良好，并且能够扩展到足以支持所有应用程序。这里的性能测试将非常有用。企业架构师的主要任务之一是确定所有应用程序的大小，并为企业服务层环境推荐规范
虽然有点晚，但我希望提供一些指导，以便阅读本文的人能够从企业IT生态系统中获得最新信息。
建议/建议，
- 了解组织的企业体系结构原则
- 例如，如果它说重用和回收，那么在您的体系结构设计中选择可重用性
- 如果它能促进创新，就不要使用UI框架标准化，因为现在多模式应用程序使用的每个应用程序/服务如网络、台式机、移动设备、平板电脑和设备
- 因此，将重点放在构建服务层上，重新表述这个层，将其称为SOA/neneneba API层，使用RPC和REST模式开发服务，让您的投资组合/业务开发团队发布API/服务。将其编入目录
- 因此，无论谁想在任何UI框架中进行开发，都可以让他们进行实验，最终在一两个UI框架中解决问题
- 正如Ahmed Hashim所指出的，如果您需要发布/发布事件和编排，以及交换数据的生态系统中的许多业务线应用程序，请投资ESB