• 代码：一堆组织好的文本，也叫源代码，源码。
• 程序：可执行的一组指令，通常以二进制文件的形式存在。对于脚本语言，也可以是源码的形式存在。
  有种常见的说法是程序 = 数据结构 + 算法。
• 软件：程序 + 资源（数据、文档、工程文件等）。
• 功能：使用软件实现的一个确定目标。
• 部署环境：

用户视角：

• 产品：产品和销售设计，面向用户，一组功能和价格的封装。可能是系统，可能是别的系统上的应用。

管理视角：

• 项目：团队 + 资源，来完成具体任务和目标。

架构视角：

• 系统：一些相关的事物组合成一个有机整体，通过对资源的管理和利用，来实现某些功能。
• 应用：运行于一个系统之上，独立且内聚，实现特定的功能，或为系统增加一些新的功能。
• 拓展：和应用类似，但是其作用是对系统原有功能进行辅助或者增强。

功能视角：

• 服务：程序或软件系统对外提供某种功能（完成某些任务），或许还会提供一些交互方式（网络协议，Web 页面，API，GUI）。
  一个系统可能是多个小的服务组成，整个系统对外又可以说是提供一个服务。
• 平台：也是服务，强调的是对使用者提供某种支撑。用时髦的话讲，就是赋能。
  一般来讲是，应该是一个强大、复杂的服务。
  管理平台，日志平台，商户平台，开放平台。

开发视角：

• 库 library，组件 component，插件 plugin，控件：都是指可复用的代码，或者可调用的二进制程序。他们之间的差异就是在于不同的使用场景。
• 代码仓库：源代码版本管理中的概念。也有人将仓库称为项目，我认为是很不贴切的，即使这个项目的所有代码都在一个仓库内。
• 模块：独立（或相对独立）的一段程序，可以是库、组件、服务，也可以是程序中一个相对内聚的部分。
  甚至，子系统也可以说是系统的一个模块。

反过来思考

假设有这么一个项目组，共 5 个人，开发了一个项目，由 10 个服务组成的一个项目管理系统。
基于这套系统，又封装成了两个产品，分别面向开发团队和一般团队。
一个团队，一个项目，一个系统，两个产品。

后来业务发展、商务合作、法务合规的缘故，项目组另外再部署一套一模一样的系统，专门为某个客户服务。
一个团队，一个项目，两套系统，三个产品。

再后来，这套专有系统持续创造较大的利润，项目组为他另外开一个新的项目进行管理，需求、开发进度等等都独立开来。但是还是这个团队来做。
一个团队，两个项目，两套系统，三个产品。

这个逻辑有问题么？