我混淆了这两种架构的差异。
通常，Monolithic Architecture 是指将应用程序的不同组件组合成单个业务逻辑。
而且，Service Oriented Architecture 是指由离散且松散耦合的软件代理组成的应用程序，它们执行所需的功能。
但我了解到，OOP 和设计模式的目标是“一个功能应该有一个责任”和“减少依赖关系以增加功能的重用”。
所以我的问题是：
1. 单体架构是否遵循 OOP？
2.这两种架构的区别。
【问题讨论】：
标签： oop architecture soa monolithic
1.单体架构是否遵循 OOP？
好的。是的。如果它是程序性的，或者如果它是功能性的，它会更难写。在我工作过的所有专业公司中，他们都拥有 OOP 和像 MVP 这样的框架，它们也包含在内。根据我为有问题产品的公司提供支持的经验，它们往往一团糟。真的很顺利，很少重复使用，如果需要扩展一个 1MB 的东西，唯一的方法就是扩展整个 100MB 的解决方案。
2。这两种架构之间的差异。
面向服务的架构 IMO 认为每个功能都可以是一个 API，其面向服务。面向对象编程有几个租户，多态、可重复、封装（和抽象），它是一种编程风格，几乎与过程编程等相反。
当您设计一项服务时，假设它是一个天气应用程序，它可以告诉温度并进行预测。您将希望拥有一个抽象的通用 Weather 类，使其支持摄氏度和华氏高度实现，并且您可以获得一些多态性，或者可能添加一个接口来支持不同的位置或高度，并使用听起来像 GetTemp 这样抽象的真正通用函数名称（使用 City、State、Altitude 的函数重载）将其封装在 Weather 类中。
因此，您在这里设计它时要考虑到面向服务和可靠的 OOP 程序集。
“一个功能应该有一个责任”和“减少依赖以增加功能的重用”。
对于第二个预测温度的服务，它将进行一些计算并花费时间进行计算，因此我们希望将其隔离，以便我们可以独立扩展它。您可以通过使用不同的项目来做到这一点，而不是在消息传递技术（SQS、RabbitMQ 等）中相互引用，因此它们是松散耦合的。
注意：我们可以简单地将静态 GetTemp 结果缓存在其他项目中，以便轻松扩展系统的该部分。
【讨论】：