软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。这使它们可再用和允许人员同时协作、编写及研究不同的模块。
软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
从逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理的角度来拆分系统后，得到的单元就是“组件”。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。其实，“组件”的英文 component 也可翻译成中文的“零件”一词，“零件”更容易理解一些，“零件”是一个物理的概念，并且具备“独立且可替换”的特点。
框架与架构框架是和架构比较相似的概念，且两者有较强的关联关系，所以在实际工作中，这两个概念有时我们容易分不清楚。
框架与架构的区别：
软件框架（Software Framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
关键部分提炼：
框架是组件规范：例如，MVC 就是一种最常见的开发规范
框架提供基础功能的产品：例如，WebApi 是 MVC 的开发框架，除了满足 MVC 的规范，.NET Core WebApi 提供了很多基础功能来帮助我们实现功能，包括Http请求，过滤器（[HttpGet]）等很多基础功能。
软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。
单纯从定义的角度来看，框架和架构的区别还是比较明显的，框架关注的是“规范”，架构关注的是“结构”。框架的英文是 Framework[ˈfreɪmwɜ:rk]，架构的英文是 Architecture[ˈɑ:rkɪtektʃə(r)]。EF 的英文文档标题就是“Entity framework”。
重新定义架构参考维基百科的定义，架构重新定义为：软件架构指软件系统的顶层结构。
首先，“系统是一群关联个体组成”，这些“个体”可以是“子系统”“模块”“组件”等；架构需要明确系统包含哪些“个体”。
其次，系统中的个体需要“根据某种规则”运作，架构需要明确个体运作和协作的规则。
第三，维基百科定义的架构用到了“基础结构”这个说法，我改为“顶层结构”，可以更好地区分系统和子系统，避免将系统架构和子系统架构混淆在一起导致架构层次混乱。
总结提炼上述概念架构是顶层设计；
框架是面向编程或配置的半成品；
组件是从技术维度上的复用；
模块是从业务维度上职责的划分；
系统是相互协同可运行的实体。
架构设计三原则合适原则、简单原则、演化原则，架构设计时遵循这几个原则，有助于做出最好的选择。
合适原则合适原则宣言：“合适优于业界领先”。
优秀的技术人员都有很强的技术情结，当他们做方案或者架构时，总想不断地挑战自己，想达到甚至优于业界领先水平是其中一个典型表现，因为这样才能够展现自己的优秀，才能在年终 KPI 绩效总结里面骄傲地写上“设计了 XX 方案，达到了和 Google 相同的技术水平”“XX 方案的性能测试结果大大优于阿里集团的 YY 方案”。
但现实是，大部分这样想和这样做的架构，最后可能都以失败告终！
为什么会这样呢？
再好的梦想，也需要脚踏实地实现！这里的“脚踏实地”主要体现在下面几个方面。
将军难打无兵之仗
大公司的分工比较细，一个小系统可能就是一个小组负责，比如说某个通信大厂，做一个 OM 管理系统就有十几个人，阿里的中间件团队有几十个人，而大部分公司，整个研发团队可能就 100 多人，某个业务团队可能就十几个人。十几个人的团队，想做几十个人的团队的事情，而且还要做得更好，不能说绝对不可能，但难度是可想而知的。
没那么多人，却想干那么多活，是失败的第一个主要原因。
罗马不是一天建成的