细说业务逻辑
seata 的用法 -回复
seata 的用法-回复【seata 的用法】是指分布式事务解决方案seata 在实际应用中的具体用法和步骤。
为了更好地理解和掌握seata 的用法，本文将从以下几个方面详细介绍：seata 的背景与概念、seata 的基本组件、seata 在项目中的集成方法、seata 的具体使用步骤、seata 的优缺点以及未来的发展方向。
一、背景与概念分布式事务是在分布式系统中执行的事务操作，它具有原子性、一致性、隔离性和持久性的特性。
然而，在分布式系统中，由于数据的分布和资源的异地，传统的ACID 事务模型很难满足分布式事务的需求。
因此，seata 应运而生，它是一个开源的分布式事务解决方案，提供了一套完备的分布式事务解决方案。
二、seata 的基本组件seata 主要由三个基本组件构成：Transaction Coordinator (TC)、Resource Manager (RM) 和Transaction Manager (TM)。
其中，TC 负责全局事务的协调，RM 负责事务的资源管理，TM 负责事务的发起和管理。
三、seata 在项目中的集成方法为了在项目中使用seata，首先需要添加seata 的依赖包到项目中。
根据项目的实际情况，可以选择使用seata 提供的全局事务管理器或自定义的事务管理器。
其次，需要进行相关配置，包括配置TC、配置RM 和配置TM。
最后，根据项目的具体业务需求，使用seata 提供的API 进行事务的控制和管理。
四、seata 的具体使用步骤使用seata 进行分布式事务管理主要可以分为以下几个步骤：1. 初始化seata 环境：首先，需要在项目中初始化seata 的环境，包括创建数据库和表、配置seata 的相关参数等。
2. 业务代码改造：将原先的业务代码进行改造，使其支持分布式事务。
具体来说，可以通过注解的方式标记需要参与分布式事务管理的业务方法。
3. 开启事务：在业务方法的开头部分，通过seata 提供的API 调用开启事务的方法，标记业务操作参与全局事务。
软件详细设计说明书模板
****项目详细设计说明书编制：日期：审核：日期：批准：日期：XXXX公司文档修订记录目录1. 引言 (1)1.1文档目的 (1)1.2参考资料 (1)1.3术语定义 (1)2. 任务概述 (1)2.1需求概述 (1)2.2运行环境 (2)2.3条件与限制 (2)3. 总体设计 (2)3.1设计目标 (2)3.2设计思想 (2)3.2.1 设计原则 (2)3.2.2 设计方法 (3)3.3总体架构 (3)3.4功能架构 (3)3.5技术架构 (4)3.6网络（部署）架构 (4)3.7外部接口 (4)3.8组件复用设计 (4)4. 系统功能设计 (4)4.1清单管理（维护功能设计举例） (5)4.1.1 清单维护 (5)4.2质量查询（查询功能设计举例） (6)5. 内部接口设计 (7)5.1内部接口概要设计 (7)5.2对象接口详细设计 (7)5.2.1 功能1业务对象 (7)5.2.2 功能2业务对象 (7)6. 数据结构设计 (7)6.1逻辑结构设计 (7)6.2物理结构设计 (8)7. 运行效率设计 (8)7.1性能瓶颈分析 (8)7.2性能设计措施 (8)8. 安全性设计 (8)8.1应用安全 (8)8.2数据安全 (9)8.3外部安全 (9)9. 质量属性设计 (9)9.1易用性设计 (9)9.2可靠性设计 (9)9.3兼容性设计 (9)10. 出错处理设计 (10)10.1出错输出信息 (10)10.2出错处理对策 (10)1.引言1.1文档目的[阐明编写详细设计说明书的目的，指明读者对象。
]本文档定义了本系统应该完成的主要任务、系统总体设计、系统接口设计、数据结构设计、运行设计等内容。
本文档的预期读者包括甲方项目组相关人员、乙方项目组成员（包括项目经理、程序员、市场相关人员等）、监理方相关人员，以及其他与本项目建设相关的人员。
1.2参考资料[本小节应完整列出此详细设计说明书中其他部分所引用的任何文档。
软考高级系统架构师知识点
软考高级系统架构师知识点一、知识概述《软考高级系统架构师知识点》①基本定义：软考高级系统架构师是一个针对计算机系统架构相关知识和技能的高级别认证考试涉及的知识点。
简单说就是关于怎么把一个计算机系统，像建大楼似的规划好、设计好，从硬件到软件，各个部分怎么搭配让系统性能优秀、可靠、安全等方面的知识。
②重要程度：在计算机领域尤其是涉及大型系统开发和架构设计方面那可是相当重要的。
就好比建高架桥得有专业设计师设计好结构一样，大型软件系统也需要架构师设计好系统结构。
这能让企业的软件项目顺利进行，节约成本避免走弯路。
③前置知识：像编程语言（如Java、C++等），操作系统基础（懂得Windows、Linux这些系统的常规操作原理等），数据库基础（知道怎么创建、管理数据库等）这些都得先掌握些。
④应用价值：实际应用场景可多了去了。
像电商公司开发大型购物平台，社交软件公司搭建聊天应用，都需要系统架构师来设计系统框架才能应对高并发、海量数据存储这些问题。
二、知识体系①知识图谱：这个知识点在软考体系里处于高级水平的重要位置，涵盖从系统需求分析开始，到架构设计，再到最后的架构评估优化这么一个整体流程相关的知识。
②关联知识：它和软件工程知识联系密切，因为软件从开发到部署都要在设计好的架构里进行。
还有计算机网络知识，架构师得考虑分布式系统架构下网络传输等问题。
③重难点分析：掌握难度比较大。
一方面理论知识多而且抽象，像架构风格这些。
另一方面还得有实际项目经验。
关键点在于把理论结合实际项目。
④考点分析：在考试中占很大比例。
考查方式可能有选择题分析概念，简答题阐述架构设计思路，还有可能给个案例让你去分析架构的优劣并改进。
三、详细讲解【理论概念类】①概念辨析：核心概念有比如架构风格，简单说就是系统架构像盖房子的风格有欧式、中式那样，有分层架构、事件驱动架构等不同风格，就是组织系统各部分的一种方式。
②特征分析：以分层架构为例，它的主要特点就是把系统按不同功能分层，像表现层、业务逻辑层、数据访问层。
MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA
通俗名解：MRD、BRD、PRD、FSD、PSD、SRS、ROI、CPA、(2009-11-24 14:59:19)转载标签：it 分类：网站运营经常听到有朋友在群里面问一些专有名词的缩写含义，恰巧在网上找资料看到这个帖子，故此转帖过来。
希望对朋友们有所帮助。
MRDMarket Requirements Document，市场需求文档。
获得老大的认同后，产品进入实施，需要先出MRD，具体来说要有更细致的市场与竞争对手分析，通过哪些功能来实现商业目的，功能/非功能需求分哪几块，功能的优先级等等。
实际工作中，这个阶段PD可能的产出物有Mind Manager的思维图，Excel的Feature List等。
市场需求文档（MRD）重点放在为一个被提议的新产品或者现有产品的改进定义市场需求。
与BRD指出商业问题和解决这些问题的解决方案不同，MRD更深入提议解决方案的细节。
它包括一些或者所有这些细节：a. 解决商业问题所需要的特色b. 市场竞争分析c. 功能和非功能需求d. 特色/需求的优先级e. 用例MRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。
MRD通常是一份连续的5-25页Word文档，或者正如之后描述那样在一些机构中甚至更长。
BRDBusiness Requirements Document，商业需求文档。
这是产品声明周期中最早的问的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是和老大们过的ppt，所以也就比较短小精炼，没有产品细节。
商业需求文档重点放在定义项目的商业需求。
BRD要能说出客户碰到的一个或多个商业问题，并且通过公司的产品能够解决这些问题。
接着建议一个方案——通常是新产品或者现有产品的改进来解决这些问题。
BRD也可能包括一个高级的商业案例，例如收益预测，市场竞争分析和销售/营销策略。
BRD通常是由拥有产品经理，产品营销经理或者行业分析师头衔的人撰写的。
冷静下来,细数中台有哪些坑
冷静下来，细数中台有哪些坑1、中台源2009 年阿里共享业务事业部诞生，它在多年后承接了阿里的中台的重任2010 年 6 名资深游戏开发者创立了 Supercell 公司，旗下拥有《部落冲突》，《皇室战争》，《海岛奇兵》，《卡通农场》这四款超现象级产品。
2015 年中，据说马云带领高管拜访了芬兰赫尔辛基的Supercell。
Supercell 公司员工不多，Supercell 每个团队员工不超 7 人，团队自己决定做什么产品，实现产品快速开发。
这次访问据说给阿里高管带来了极大的震撼，于是大家开始思考快速发展的信息时代中公司的架构到底应该是怎么样的。
2015/12 阿里 CEO 逍遥子的一封内部邮件打响了阿里内部进行“大中台，小前台”组织架构升级的指示2015 年末，滴滴启动中台战略，构建业务中台主要出于四方面：专业深度，人力资源，用户体验，全局打通2017/12 滴滴分享了如何构建自己的中台2018/1 京东进行组织架构调整2018 下半年，爱奇艺开始规划做中台2018/7 百度总裁陆奇离职2018/12 京东宣布采用前台，中台，后台的组织架构2018/12 百度内部宣布进行架构调整2019/3 字节跳动对外透露正在搭建“直播大中台”2019/5/6 上半年，知乎创始人于第二届数字中国建设峰会接受专访时提到知乎的中台2019/5/21 腾讯召开了全球数字生态大会，会上腾讯高级副总裁提出了“开放中台能力，助力产业升级”和“开源协同”和“自研上云”，然后“中台”立马就被带火了。
从百度搜索指数可以明显发现，从 5/21 起中台搜索量指数往上涨2019/8/9 小米在 ITex 供需博览会上提出小米中台进行业务 + 数据 + 技术建设2019/10 爱奇艺在 QCon 全球软件开发大会上对爱奇艺中台进行介绍一、大厂的中台1、腾讯All in产业互联网。
腾讯的技术委员会，对标的是阿里巴巴的中台事业部，而不是外界所解读的对标阿里“达摩院”。
详细设计文档
详细设计文档1. 引言本文档旨在对XXX系统的详细设计进行描述。
XXX系统是一个XXXX的系统，用于XXXXX。
该文档将涵盖系统的整体结构、模块的设计和交互流程等内容，有助于开发人员理解系统的技术细节和工作流程。
2. 系统结构XXX系统基于XXX架构，采用了分层结构，以实现系统的高内聚和低耦合。
系统的主要结构如下：•用户界面层：负责和用户进行交互，接收用户输入并将结果显示给用户。
•控制层：处理用户界面层传递的请求，负责调用适当的业务逻辑进行处理，并将结果返回给用户界面层。
•业务逻辑层：负责实现系统的核心业务逻辑，处理各种业务需求。
•数据访问层：提供对数据的访问和操作，对数据库进行读写操作。
3. 模块设计3.1 模块A模块A是XXX系统的核心模块，负责处理XXXX。
模块A的设计主要包括以下几个部分：•模块接口：定义了模块暴露给其他模块使用的接口，包括XXX、XXX 等。
•内部数据结构：描述了模块内部使用的数据结构，包括XXX、XXX 等。
•模块算法：描述了模块内部使用的算法，包括XXX、XXX等。
•模块流程：描述了模块的工作流程，包括XXX、XXX等。
3.2 模块B模块B是XXX系统的辅助模块，负责处理XXXX。
模块B的设计主要包括以下几个部分：•模块接口：定义了模块暴露给其他模块使用的接口，包括XXX、XXX 等。
•内部数据结构：描述了模块内部使用的数据结构，包括XXX、XXX 等。
•模块算法：描述了模块内部使用的算法，包括XXX、XXX等。
•模块流程：描述了模块的工作流程，包括XXX、XXX等。
4. 交互流程本节描述了用户与系统之间的交互流程。
用户通过用户界面层与系统进行交互，主要包括以下几个步骤：1.用户打开系统，进入登录界面。
2.用户输入用户名和密码，点击登录按钮。
3.系统验证用户身份，并根据用户权限进行相应的授权。
4.登录成功后，系统显示主界面，用户可以进行XXX操作。
5.用户进行XXX操作，系统接收用户操作请求。
合同条、款、项的顺序
合同条、款、项的顺序合同是人们在法律框架下为了实现共同目标而签订的一种约定，包括条款和项目等细节内容。
在撰写合同时，条、款、项的顺序对于合同的层次结构和阅读体验是非常重要的。
本文将探讨合同条、款、项的顺序以及如何合理安排，以确保合同的准确性和易读性。
一、什么是合同条、款、项在进行合同撰写之前，我们需要明确合同条、款、项的定义：1. 合同条：合同的最高层次，通常对应于合同的主要内容和要求。
例如，房屋买卖合同中的购房者权益、房屋交付等就可以作为合同条。
2. 合同款：合同条的下一级，用于具体描述合同条中的各项内容。
例如，在房屋买卖合同中，购房者权益下的房屋交付、房屋质量保证等可以作为合同款。
3. 合同项：合同款的下一级，更加具体和详细地描述合同款中的各个要求和规定。
例如，在房屋交付这一合同款中，可以包括房屋交付时间、房屋验收标准等合同项。
二、合同条、款、项的顺序安排在合同的撰写过程中，条、款、项的顺序直接影响了合同的逻辑性和可读性。
一般来说，可将条款按照从整体到细节逐级展开，如下所示：1. 首先，合同条的顺序应该按照合同的主要内容和重要性进行排列，以保证合同的主旨清晰。
可以根据具体情况编排，一般从合同的基本原则或目的开始，依次罗列重要的合同条。
2. 接下来，每个合同条下面按照次要程度或者业务逻辑的关系排列各个合同款。
合同款是对于合同条的具体描述和规定，可以根据条款的需要进行逻辑排序。
3. 最后，在合同款下面，按照逻辑顺序编排各个合同项。
合同项是对合同款的进一步细化和具体规范，以实现合同的明确和可执行性。
三、合同条、款、项的撰写要点在撰写合同条款和合同项目时，请注意以下几点：1. 简明扼要：合同应该避免冗长复杂的描述，条款和项目的表述应清晰、简明扼要，避免造成理解的困惑。
2. 层次清晰：条、款、项之间的逻辑关系应该明确，排列上要符合逻辑结构，确保合同的逻辑性和一致性。
3. 按重要性排序：在撰写合同时，应该将最重要的内容放置在最前面，以确保对合同主要内容的准确阐述。
六边形架构、分层架构及其它
六边形架构、分层架构及其它作为⼀个后端程序员，MVC三层架构的模式相信⼤家都不会陌⽣，三层分别从上⽽下排布，只能由上层调⽤下层。
⼀般越往下层越通⽤，越上层越细节。
随着某些核⼼业务的访问量发展，通常我们需要去进⾏优化的措施，⽐如加缓存，加MQ，换数据源1.缓存可选redis，memcache2.MQ可选kafka，rocketmq，rabbitmq3.数据源可选：mysql，mongodb，elasticsearch复制代码当然，我们在做这些优化的时候，会将mq,mongodb等看成基础设施层。
由此衍⽣出四层的架构，infrastructure⾥封装redis和mq的通⽤调⽤逻辑这些优化的动作，通常不会改变原有的业务逻辑。
但是为了做优化，我们会将它写在service层，⽐如：1.执⾏成功就发个MQ2.执⾏某个事件的时候，同步⼀下缓存3.依赖关系为，domain依赖infrastructure问题点：按道理来说，domain层是写业务逻辑的，优化不会涉及到业务逻辑的改动，但是却改动了domain层。
由于domain层依赖了infrastucture的原因，导致业务依赖于具体的实现技术。
所以，为了将业务与具体实现做分离，我们采⽤依赖倒置的⼿段去重构依赖倒置原则的包含如下的三层含义：1.⾼层模块不应该依赖低层模块，两者都应该依赖其抽象2.抽象不应该依赖细节3.细节应该依赖抽象⾼层模块不依赖低层模块：那就可以在domain层定义存储的接⼝，如AARepository，但是不写具体的技术实现抽象不依赖细节：在domain层⾥，不依赖其他包的类，如⽤到数据存储时，直接调⽤domain的抽象接⼝即可⾼层通过依赖注⼊的⽅式，将基础设施的实现传到domain层中如此⼀来，我们的架构就不再是分层的结构（从上往下调⽤）。
⽽是将抽象全部堆在domain层，将细节全部往application和infrastructure去推。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
细说业务逻辑2010-08-02 作者：张洋前言记得几个月前，在一次北京博客园俱乐部的活动上，最后一个环节是话题自由讨论。
就是提几个话题，然后大家各自加入感兴趣的话题小组，进行自由讨论。
当时金色海洋同学提出了一个话题——“什么是业务逻辑”。
当时我和大家讨论 MVC的相关话题去了，就没能加入“业务逻辑”组的讨论，比较遗憾。
其实，一段时间内，我脑子里对“业务逻辑”的概念也是非常模糊的。
但在不断地阅读、思考和实践过程中，这个概念及其相关的内容才在我脑子里渐渐清晰。
我想，很多朋友也许也对这个概念不是很了解，所以愿意结合既有资料和自己的思考，总结一篇关于业务逻辑的概述性文章，一则与朋友们分享探讨，二则也是为自己对业务逻辑的学习做一个总结和提升。
因为我还不敢说对业务逻辑内涵及外延理解的非常充分，所以文中如有不当之处，还请各位不用客气，尽管批评就好！内容提要===================前篇=====================前言内容提要1、我把业务逻辑丢了！——找回丢失的业务逻辑2、细说业务逻辑2.1、业务逻辑到底是什么2.2、业务逻辑的组成结构2.2.1、领域实体（Domain Entity）2.2.2、业务规则（Business Rules）2.2.3、完整性约束（Validation）2.2.4、业务流程及工作流（Business Processes and Workflows）2.3、业务逻辑层职责相关争议2.3.1、争议一：数据的格式化2.3.2、争议二：数据合法性及完整性验证2.3.3、争议三：CRUD2.3.4、争议四：存储过程===================后篇=====================3、业务逻辑的架构模式及实现3.1、Transcaton Script3.1.1、概述3.1.2、分析3.2、Table Module3.2.1、概述3.2.2、分析3.3、Active Record3.3.1、概述3.3.2、分析3.4、Domain Model3.4.1、概述3.4.2、分析3.5、各种架构模式的比较及选择4、结束语参考文献1、我把业务逻辑丢了！——找回丢失的业务逻辑相信朋友们基本都是软件开发人员。
不论身处什么职位，我们的工作都有一个共同的目标——制作软件产品。
而所谓的软件产品，一定是在某个领域内去实现某些业务。
如此看来，“业务逻辑”本应和“软件产品”是紧紧绑在一起的，没有业务逻辑，何来软件产品？但是，我发现一个奇怪的现象，一说业务逻辑，很多人就无法形成清晰地印象。
例如，经典的三层架构：表示层、业务逻辑层和数据访问层，一提到表示层或数据访问层，大家脑子里马上能产生出清晰的概念，但一提到业务逻辑层，就有点模糊了，或者完全不知道其是什么，或者有个模糊的轮廓，但对其具体的职责、结构不是很清楚。
真是奇了怪了！我们天天和业务逻辑打交道，搞不清业务逻辑是什么。
对于这个奇怪的现象，我思前想后，结合自身的教训（我也曾很长时间搞不清业务逻辑），终于弄清楚了其原因——这和我们接触这个概念的途径和认知结构有莫大关系。
不知道有多少人和我一样，首次接触“业务逻辑”这个概念是从分层架构中的“业务逻辑层”概念开始的，我相信不在少数。
事情坏就坏在这里！为了让朋友们直观看清“业务逻辑”的概念是怎么被我们丢掉的，请大家看一个图，这个图展示了很多人对“业务逻辑”的认知过程。
图1-1、狭义的认知分解过程如图1-1所示，我们先接触了分层架构，然后对每个层产生了初步的认识。
其中，由于表示层和数据访问层的代码职责清晰明确，基本能正确认识。
但是，由于我们接触的分层架构的Demo大多业务极其简单，又基本是CRUD操作集中型的业务。
所以，我们脑子中就产生了疑问：这个所谓的业务逻辑层是干什么的？怎么就简单封装了一下数据访问层的操作？这有存在的必要吗？由于有了这种“先入为主”的误导，使得很多朋友脑中将“业务逻辑”和“业务逻辑层”两个概念混淆了，始终想不明白这东西到底是什么，做什么用的。
再加上很多朋友所看的、所做的系统都是CRUD操作集中型的，就形成了“业务逻辑貌似就是对数据访问操作的简单封装”这一片面概念。
到底这一概念有没有错呢？其实没错，因为在简单的、CRUD操作集中型软件中，业务逻辑基本就是对数据访问简单的封装。
但是，无错不代表全面，这是一种狭义的业务逻辑理解，而且是狭义中的狭义。
为什么这么说呢？因为我们不但是在“业务逻辑层”这么一个狭义范围内去理解业务逻辑，而且还是CRUD 集中型操作这种“非常瘦”的业务逻辑层范围内去理解，所以，可谓是在狭义的基础上的狭义。
当我们把这么一个“狭义中的狭义业务逻辑”与“业务逻辑”等同起来时，误会、迷茫、困惑、不屑就出现了。
这就如同，给你一只温顺的哈巴狗，还是病怏怏的、无精打采的小哈巴狗，而你把这只“病怏怏的小哈巴狗”与“狗”的概念等同起来了。
那么你一定就会为有人养狗看家和警察养狗当警犬抓坏人而困惑：这东西这么弱小，我一脚就踩死了，怎么弄用来看家和抓坏人呢？进而可能会产生“狗狗无用论”，“狗狗废品”等观念。
当然，在现实中，很少有人只见过小哈巴狗而没见过狼狗等其它狗类，所以，故事中的误会对“狗”一般是不存在的。
但在现实中，确实有很多人只见过业务逻辑中的“小哈巴狗”，却没有见过业务逻辑中的“狼狗”、“藏獒”，所以，这种误会在对“业务逻辑”的理解上广泛存在。
那么，广义的情况究竟是怎么样的？请看下图。
图1-2、广义的认知分解过程（注意！凡是不特别说明，下文中所有“数据”一词都指需要持久化的数据，而不包括内存中的临时数据。
请各位留心。
）如图1-2所示，广义的认知分解应该是这样的：软件产品都是在某个领域内实现某些特定业务，所以，软件产品天生应该分解为界面交互部分和业务逻辑部分，其中业务逻辑部分是软件产品的核心，它客观存在于软件产品内部，但是无法对使用者产生直观刺激，因此业务逻辑不能与使用者直接交互。
而界面交互部分是业务逻辑与使用者进行交流的接口，使用者通过界面交互部分，与业务进行交流，从而使得软件产品发挥其作用。
而在具体实现系统时，界面交互部分演化成表示层，业务逻辑部分演化成业务逻辑层。
所以，可以认为，数据访问层不是软件产品自然演化的直接产物，之所以出现数据访问层，是因为某些产品的业务属于“数据操作集中型”业务，为了实现隔离、复用等目的，架构师从业务逻辑中分离出了频繁使用的数据访问业务，形成了单独的数据访问层。
从广义来说，可以认为数据访问隶属于业务逻辑，因为，数据访问操作实际上也是业务逻辑的一部分。
总结一下几个要点：（这几个要中的业务逻辑均指广义业务逻辑）1）软件产品自然的可分为界面交互部分和业务逻辑部分。
2）从空间结构上看，业务逻辑和数据访问不是并列关系，而是隶属关系——数据访问隶属于业务逻辑。
虽然在具体系统实现层面，数据访问层和业务逻辑层是并列存在，但从概念本质层面上分析，两者是隶属关系。
3）从时间结构上看，应该是先有业务逻辑的概念，才有数据访问的概念。
业务逻辑衍生自软件本身，数据访问衍生自业务逻辑。
4）因为业务逻辑是软件产品自然的一部分，所以拥有业务逻辑是软件产品的必要条件（读者可以试着举出一个不包含业务逻辑的软件）。
但是一个软件可以没有数据访问，如“计算器”、“不带存档的小游戏”等。
利用以上论述要点和认知分解，朋友们可以试试在脑中重新构筑狭义和广义“业务逻辑”的概念。
看能不能把我们丢掉的业务逻辑概念找回来。
关于业务逻辑更多的细节，将在下文中讨论。
2、细说业务逻辑2.1、业务逻辑到底是什么在第一大节里说了那么多，相信各位基本已经形成“业务逻辑”的概念了。
如果我在这里再啰嗦什么，我不嫌累各位也要嫌烦了。
所以，这里我仅给出两个定义。
广义上的义务逻辑——软件本身固有的一种品性，自然存在于软件产品内部，是软件具有的在某个业务领域内的逻辑，是软件的核心和灵魂。
软件产品除界面和交互外的一切都可看作是广义业务逻辑。
狭义上的业务逻辑——等同于分层架构中“业务逻辑层”的职责，是软件中处理与业务相关任务的部分，一般狭义上的业务逻辑不包含数据持久化，而只关注领域内的相关业务。
对于以上两种定义，希望朋友们不要割裂开来看，而要辩证统一的去看，这样，才能构建一个完整而辩证统一的“业务逻辑”概念。
在下文中，将不再明确区分狭义和广义，“业务逻辑”一词将代表两者的辩证统一体。
2.2、业务逻辑的组成结构业务逻辑作为一个高层次概念，其内在结构也是非常丰富的，下面我们深入其里，去探寻一下业务逻辑都是由哪些更底层的部分构成的。
2.2.1、领域实体（Domain Entity）通俗的说，领域实体就是这个领域内有哪些东西。
例如，银行业领域内有账户、支票、前台营业员等实体；B2C电子商务领域有商品、订单、交易等实体；魔兽世界游戏的领域内有角色、种族、道具、魔法等实体；高等代数领域有矩阵、行列式等实体。
领域实体是某个领域内各种对象的抽象，可以用名词表示（可以是具体名词或抽象名词，甚至动名词，只要其具有名词性），构成了整个业务逻辑的骨骼和静态模型。
一般每个领域实体有自己的一些属性和行为。
顺便说一句，领域实体的存在时OOA&D的基础。
在具体的软件系统中，领域实体往往会根据架构的不同有不同的映射存在形式。
其中一种叫做Business Object（BO），即业务对象，某些文献称其为“充血实体类”，这种对象完整抽象了领域内的某个实体，封装了此实体相关属性和行为。
在面向对象的设计和架构中，这种实体类很常见。
另一种叫做Data Transfer Object（DTO），某些文献称其为“贫血实体类”，其特点是仅有属性，不存在行为。
这种实体类主要负责整体性传递数据。
另外，与BO不同的是，DTO可以不抽象领域实体的全部属性，而只根据需要抽象一部分。
例如，某个“User”实体存在很多属性，但如果某个方法仅需要其联系方式，可以设计一个DTO，仅有id，email，address，phone等就够了。
在面向过程的设计和架构中，这种实体设计比较常见。
2.2.2、业务规则（Business Rules）业务规则就是某个领域内运作的规则，构成了整个业务逻辑的灵魂和动态模型。
业务规则作用于领域实体，领域实体遵从业务规则进行运作。
如：在银行领域内，“转账时从A账户扣除相应款项，在B账户添加相应款项，并从A账户扣除相应手续费，并通过某些途径通知A和B账户的户主”就是一条规则。
需要注意的是，业务规则比较抽象，并不是需求，需求需要具体且无二义性，而业务规则只是抽象的一种描述，例如，通知户主的途径是什么？电子邮件？电话？短信？并没有具体描述，但在规则中有“通知”这一项，因此不能将业务规则等同于需求。
2.2.3、完整性约束（Validation）领域实体和业务规则构建了业务逻辑的主体，但在这主体之上，还存在着一个限制，这就是完整性约束。