面试官：什么是业务？
我：是不是软件的一些功能点。
面试官：什么是模块。
我：比如做个登录页面，就可以是个模块，所以一个页面的功能就可以看做是一个模块。
面试官：什么是业务逻辑
我：业务上的逻辑
面试官：业务逻辑层是做什么的。
我：处理业务逻辑的其实面试官提问的这些问题，我还真有点摸不着头脑。请大侠指点。
我：是不是软件的一些功能点。
面试官：什么是模块。
我：比如做个登录页面，就可以是个模块，所以一个页面的功能就可以看做是一个模块。
面试官：什么是业务逻辑
我：业务上的逻辑
面试官：业务逻辑层是做什么的。
我：处理业务逻辑的其实面试官提问的这些问题，我还真有点摸不着头脑。请大侠指点。
我：与漂亮妹妹的交往过程的各种活动。面试官：什么是模块。
我：与漂亮妹妹各种交往活动中，联系比较密切的，我通常将它们写在一个小纸条中，以便随身携带随时使用。面试官：什么是业务逻辑
我：决定和漂亮妹妹约会后，我需要考虑一下，是先看电影还是先吃饭？看电影选什么片子呢（AV行吗？）吃了饭点了白菜，她喜欢吗？做饭之后做什么呢？（饱暖思淫欲）面试官：业务逻辑层是做什么的。
我：通常我是和N个漂亮妹妹的交往的，我会做的很隐蔽，不让她们晓得。此外，别人只知道我有漂亮妹妹，却不知道有几个有多少个？
晚上，做梦了个美梦。 给LZ分享以下： 面试官：什么是业务？
我：与漂亮妹妹的交往过程的各种活动。 面试官：什么是模块。
我：与漂亮妹妹各种交往活动中，联系比较密切的，我通常将它们写在一个小纸条中，以便随身携带随时使用。 面试官：什么是业务逻辑
我：决定和漂亮妹妹约会后，我需要考虑一下，是先看电影还是先吃饭？看电影选什么片子呢（AV行吗？）吃了饭点了白菜，她喜欢吗？做饭之后做什么呢？（饱暖思淫欲） 面试官：业务逻辑层是做什么的。
我：通常我是和N个漂亮妹妹的交往的，我会做的很隐蔽，不让她们晓得。此外，别人只知道我有漂亮妹妹，却不知道有几个有多少个？呵呵
[编辑本段]定义
词目：业务
拼音：yè wù
英文：business
释义：涉及一个以上组织，按某一共同的目标、通过信息交换实现的一系列过程，其中每个过程都有明确的目的，并延续一段时间。[
模块 module；block
（一）在程序设计中，为完成某一功能所需的一段程序或子程序；或指能由编译程序、装配程序等处理的独立程序单位；或指大型软件系统的一部分。
模块有各种类型，如单元操作模块（换热器、精馏塔、压缩机等）、计算方法模块（加速收敛算法、最优化算法等）、物理化学性质模块（汽液相平衡计算、热焓计算等）等。
（二）可以组合和变换的标准单元硬件。
模块,又称构件,是能够单独命名并独立地完成一定功能的程序语句的集合（即程序代码和数据结构的集合体）。它具有两个基本的特征：外部特征和内部特征。外部特征是指模块跟外部环境联系的接口（即其他模块或程序调用该模块的方式，包括有输入输出参数、引用的全局变量）和模块的功能；内部特征是指模块的内部环境具有的特点（即该模块的局部数据和程序代码）。
(三)电路中将分立元件组成的电路重新塑封称为模块,如电源模块.他和IC本质上没什么区别.只是一般模块适用于大功率电路,是"半集成电路"而且内面可能含有IC,而IC刚是全集成电路.
（四） 在韦氏英文的词典里，“模块”一词的第1条解释是“家具或建筑物里的一个可重用的标准单元”。
业务逻辑层
关于
所谓的三层开发就是将系统的整个业务应用划分为表示层，业务逻辑层和数据访问层，这样有利于系统的开发、维护、部署和扩展。
分层是为了实现“高内聚，低耦合”。采用“分而治之”的思想，把问题划分开来各个解决，易于控制，延展和分配资源。
如下图所示
业务逻辑层
用于做一些有效性验证的工作，以更好的保证程序运行的健壮性。如完成数据添加、修改和查询业务等；不允许指定的文本框中输入空字符串，数据格式是否正确以及数据类型验证；用户权限的合法性判断等；通过以上的诸多判断以决定是否将操作继续向后传递，尽量保证程序的正常运行。
业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。