Ree*_*aid 0 architecture components system
在软件工程中如何轻松地区分系统的子系统和组件？
给他们每个人一个详细的定义..
为了让我更清楚，让我们假设该系统是一个 StackOverflow 站点，它的组件和子系统是什么？
我之所以谨慎地回答这个问题，部分原因是我们可以根据上下文有很多定义。
例如，您可以在UML文献中搜索系统和组件的定义，并发现它与操作系统书籍不同。
也就是说，这些是我对组件和子系统的简单定义。我并不是说这是完全正确的。
这只是我在投影应用程序时发现的一种在头脑中组织事物的方法。
我们先来定义一下“系统”。注意我称之为“The”而不是“a”系统。因为在这里，系统是我们的背景，我们的世界。
该系统是我们从事的项目。作为软件工程师/架构师/开发人员，您的使命是将其变为现实，维护它并使其蓬勃发展。
我对“系统”没有一个简单的定义，因为不同的项目有不同的上下文。
由于内部文化的原因，即使是不同商店的类似项目，语言也略有不同。
恕我直言，定义取决于语言，语言取决于文化，文化是从上下文演变而来的。
但我离题了。在简历中，您的定义取决于您的上下文。
例如，在 DDD 中，有必要定义一种UbiquitousLanguage 以确保每个人都在同一页面中。
我们将“蓝图”称为您用来抽象项目的图表，无论它是否采用UML、Bizagi等形式。
子系统的通用定义可以是：
从系统的角度来看，它是您顶级蓝图中的一个黑匣子。一般来说，子系统本身有一个蓝图，从它的角度来看，它就是系统。
子系统可以独立存在，并且在系统上有明确定义的目的和意义。
例子：
它们是房子的厨房、卧室和地下室。
对于SO，你可以说有一个标点子系统，负责管理用户如何赚取和失去积分。
请注意，SE 站点的每个实例都可以有这样的子系统，甚至它们可以进行通信以跟踪您在许多 SE 站点中的点。
其他示例可以是用于持久化和获取相关数据的持久化子系统。
组件的通用定义可以是：
他们很少出现在系统蓝图上，也很少自己得到蓝图。
一般来说，组件在系统之外没有任何意义。它们可以被系统和子系统使用，但其目的是通用的。
在房子里，它们是墙壁和家具。一把无处不在的椅子听起来不对，会议室里的椅子有用途，但不是一个子系统。对于 SO，组件可以是用于编写/编辑答案和问题的在线文本编辑器。
值得一提的是第三方组件：
它们本身可以是系统，甚至可以是非常复杂的系统，例如 DBMS 或jQuery JavaScript库。
一般来说，用任何蓝图来绘制它们都是错误的。它们可以在全球范围内使用，并且是优秀的工具，但它们是具有通用用途的黑匣子。对于 SO，它们可以是 SQL DBMS 和JavaScript库
总结：
子系统可以在没有其父系统的情况下存在。
组件不能单独使用，必须作为系统的一部分才能存在。
打个比方：
汽车是出行基础设施的一个子系统。
车轮是汽车的一个部件。
正如我所说，这只是恕我直言。