接下来这两篇文章里我尝试给大家讲清楚业务模块划分、逻辑分层解藕的底层逻辑和方法论，结合实际例子给大家解释明白这些。
这里我要再强调一点，这些方法论并不是用Go做项目、业务开发所独有的，只不过恰好我用了Go项目代码来实现和讲解它们。其他编程语言的项目也可以依据这些规则来划分模块和逻辑分层，另外这些方法论也不是我独创的，都是一些软件设计领域中沉淀已久的东西，很多书和网上的资料里都有，不过免费的资料和书籍中因为没有真实场景和项目所以会让你觉得不好理解。
我们分为上下两篇来讲这个事情，上篇专注理论和文字案例的讲解，下篇则主动用一些代码场景让大家加深理解，而且后面项目需求实战开发部分也会不停地实践这里介绍给大家的方法论，让你真正掌握项目模块划分和逻辑分层的精髓。
本片内容大纲如下：
业务的模块怎么划分
当我们开始写代码做项目实现需求的时候，我们往往会考虑该怎么给需求分业务模块，即使我们做的是迭代需求也会考虑该把他们写到哪个模块里，那么这就触及到一个比给变量起名还要让很多程序员头疼的问题--模块该怎么划分？
这种时候如果你不具备很好的规划能力的话往往会走两个极端：
先设计数据表，一个表就是一个模块。
管它呢，先粗略分分，能跑就行，Order模块写商品的逻辑也不影响跑啊，况且订单里是不是有商品？
上边这两种情况还是很常见的，第一种情况会让我们的项目中有太多模块、如果你用的是微服务架构的话就会有太多服务，一个服务里有不了几个接口，但是完成一个业务要调好几个服务，有同样经历的请在评论区举一下手，让我心里也平衡些......。
第二种情况不说了就是大泥球项目，未来想重构项目把混合揉在一起的逻辑拆分清楚也是个难事。
一个划分模块的通用方法
那么有没有什么方法论能帮助我们合理地给业务划分模块呢？那肯定是有呀，这个方法论是我从《微服务设计模式》、《IDDD》等几本书中介绍的方法论，结合自己多年的实践和体会总结出来的。这几本书中对于业务模块或者服务的划分都不约而同的给出了：
业务结构建模 + 聚合根的划分法。
赶快扫码订阅专栏，查看具体的实际案例分析吧。
关于模块划分、业务结构建模、聚合根的内容，如果有想更深了解怎么做系统分析的，可以访问我另外一个专栏的：
代码逻辑写在哪
好了，现在业务模块我们划分完了，以订单模块为例，我们的逻辑该写到哪呢？有的团队可能一开始做了划分，比如下面这个经典的分层。
Controller
Service
Dal
有的可能就直接Controller操作Dal 甚至 Model 直接查表狂撸啦，出现这种情况我觉得主要是两个问题：
搭建项目的时候没做好分层
做了分层，但是没讲明白每个分层该写什么逻辑
那么接下来我就给大家一次性讲清楚这些逻辑应该怎么分层。
逻辑这个词范围比较广，我们写的一切代码都可以叫逻辑，有业务逻辑、有请求验证逻辑、数据查询逻辑、与第三方平台对接的逻辑等等，我们分层就是要把这些逻辑归好类写在不同的层里。
按照我们在《项目的分层设计和约定》这篇文章中初步给大家讲解的约定，这些逻辑对于的层如下：
请求验证和数据绑定逻辑 --- Controller
外围业务逻辑 --- 应用服务
核心业务逻辑 --- 领域服务
数据访问逻辑 --- 数据访问层
第三方对接 -- Library
请扫码订阅专栏，在专栏的实战开发教程中会专门介绍它们的使用，同时还有实际需求代码来对这些方法论进行不停地实践，极大降低大家的学习难度。
订阅后，可加入专栏配套的实战项目，获得完整实战教程，同时也有专属的读者群，欢迎加入一起学习。
专栏分为五大部分，主要内容架构如下（已更新32节）：
第一部分介绍让框架变得好用的诸多实战技巧，比如通过自定义日志门面让项目日志更简单易用、支持自动记录请求的追踪信息和程序位置信息、通过自定义Error在实现Go error接口的同时支持给给错误添加错误链，方便追溯错误源头。
第二部分：讲解项目分层架构的设计和划分业务模块的方法和标准，让你以后无论遇到什么项目都能按这套标准自己划分出模块和逻辑分层。后面几个部分均是该部分所讲内容的实践。
第三部分：设计实现一个套支持多平台登录，Token泄露检测、同平台多设备登录互踢功能的用户认证体系，这套用户认证体系既可以在你未来开发产品时直接应用
第四部分：商城app C端接口功能的实现，强化分层架构实现的讲解，这里还会讲解用责任链、策略和模版等设计模式去解决订单结算促销、支付方式支付场景等多种多样的实际问题。
第五部分：单元测试、项目Docker镜像、K8s部署和服务保障相关的一些基础内容和注意事项
扫描上方二维码或者访问 https://xiaobot.net/p/golang 即刻订阅
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
