Angularjs 企业架构指南

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

我完全同意拥有一个企业服务层，它将被大多数（如果不是所有）web应用程序用于数据。但是，我不相信企业UI层

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

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

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

---

提前感谢您的帮助。

关于提供的建议：-

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

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

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

2.2一些技术（如Java门户）允许您将Portlet“具有业务逻辑的可重用UI组件”包含到任何其他门户页面中，并提供用于Portlet之间通信的API

可重用UI组件当然是显而易见的，但这是一种开发实践，并不真正影响体系结构。它有自己的开销和治理，这取决于您的项目大小。若你们有一个UI团队来为所有的项目服务，那个么这对于确保高可重用性可能是有效的

使用ESB无疑是前进的最佳方式，但它将改变您习惯的方式。有一些方面需要考虑

应用程序映射到流程，根据发现重新设计应用程序

保护企业服务层并开发基于角色的访问控制

查看您的操作工作簿，以确保在拥有企业服务层后，您可以识别问题、隔离问题并减少对使用该服务层的其他系统的影响

服务层中的一个错误或故障将影响所有系统，因此您必须提高质量，并使用“如果您还没有”一些方法来提高质量，如带完全测试自动化的持续集成（CI）

您需要检查硬件并进行容量规划，以确保企业服务层的性能良好，并且能够扩展到足以支持所有应用程序。这里的性能测试将非常有用。企业架构师的主要任务之一是为所有应用程序确定大小，并为企业服务层环境推荐规范