业务特定的发展应该遵循 SOLID 原则吗？答案

【问题标题】：should SOLID principles be followed for business specific development?业务特定的发展应该遵循 SOLID 原则吗？
【发布时间】：2015-06-23 08:50:35
【问题描述】：

我正在开发一个特定于业务的应用程序，3 个月以来，我阅读了很多关于 SOLID php 开发的文章。我真的认为这些准则可以为代码增加高价值，我想在未来的工作中开始尊重它们。但我真的对业务特定应用程序中的 SOLID dev 持怀疑态度，因为我找不到任何方法在我们当前的代码中实现它。我的项目不会被公开分享，因为它服务于真正面向业务的目的。如前所述，我阅读了很多 SOLID 文章，但这些文章以 Book 实现 Printable 接口或 Car abtracting Vehicle 父类为例。这些例子与现实世界的应用相去甚远。现实世界中面向业务的应用程序不是处理书籍或汽车，而是处理客户、产品、订单、发票、统计数据、邮件。

例如，我想开始使用接口，但我在我们的项目中找不到 2 个具有共同点/服务于类似目标的类，这可能会受益于实现接口。

所以我的问题有点简单，是否可以应用 SOLID 开发并为每个应用程序增加价值（在这种情况下，我只是还没有找到如何在我们的项目中实现它），或者这是某种为公共发展制定的指导方针意味着共享？

注意：不知道 stackoverflow 是否是发布该问题的正确网站，找不到与此问题相关的任何更好的 stackexchange 网站。

【问题讨论】：

不知道您的业务领域很难回答。但是，例如，您的所有产品是由一组固定的属性定义的，还是有不同“种类”的产品？（例如，亚马逊销售各种产品，但所有书籍都有某些可能不适用于电影的共同属性，反之亦然）
我们的业务为个体经营者提供服务。我们基本上提供发票软件和电话帮助台。我们有 3 种主要产品，它们具有共同的属性，允许访问发票服务和帮助台，并且很少有非常具体的产品（有些是订阅产品，有些是一次性产品）。我们的主要问题是数据库架构非常陈旧且设计非常糟糕。我们正在努力改进它，这就是为什么我在过去几个月里阅读了很多关于 SOLID 的内容。

标签： business-logic solid-principles

【解决方案1】：

SOLID 几乎是良好 OO 的同义词（显然不止 SOLID，但它是一个很好的基础）。

您要问的基本上是：“可以在实数系统中遵循最佳实践吗？”答案显然是肯定的！但是，要正确应用这些实践，需要大量的实践和经验。

SOLID 是经过多年的实际应用程序设计后从行业中出现的原则，旨在使系统代码库灵活。

起初，您可能看不到很多应用这些原则的机会，但那是因为您在应用解决方案之前尚未确定问题，而且这要困难得多，因为建模问题一开始可能很微妙，直到它们咬住你。

“我们的主要问题是数据库架构非常陈旧且设计得很糟糕。我们正在努力改进它，这就是为什么我在过去的几个月里阅读了很多关于 SOLID 的文章。”

SOLID 主要是关于 OO 的，良好的 OO 建模不应该关心持久性。如果您想改进您的数据库架构，那么您的方向就错了。

我强烈建议您阅读领域驱动设计 (DDD)，而不是只关注 SOLID。 DDD 就是以一种对领域和现实世界真实的方式来制作特定于领域的模型。 DDD的主要本质不在于它的战术模式，而是基于SOLID。

【讨论】：