业务代码应该怎么写

一. 前言

不知不觉也写了两年业务代码了，是时候总结一波了。

二.模块划分

首先是包的划分， controller、service、dao、model、util 等包是要有的，在正常的业务之外，我认为还可以有
filter：对请求进行处理，解析出请求参数或者登陆人信息，
context：存放线程相关的上下文，比如一次请求的参数，登陆人信息，
exception：全局处理异常，可以分开业务异常和运行时异常，业务异常还可以分级别，
logger：日志，可以有不同的级别，抽象出 api，

这些包可以抽象出一个 jar 或者 start 供其他模块使用。

三.复杂业务代码该怎么写

这里拿一个商品上架的场景举例，商品上架在用户看来就是上传内容，然后点击确认。

这个流程可以分解为三个阶段(phase)：
1.初始化阶段。
2.校验阶段
3.执行阶段

每个阶段，又可以继续分解为许多步骤。

我写过这样的需求：根据表单配置监听多种表单的消息，推送消息。这就可以拆解为一下几个步骤：
1.每种表单在产生消息时都需要发送给监听服务。
2.抽象出两个方法，一个是是否要处理，一个是处理，每一种表单类型都实现了
3.找具体类型的方法进行处理

还写过类似闹钟的表单配置，每种表单在类似闹钟的各种时间周期内，可以选择执行多次或者一次，即如果周期内执行一次，则每次都是修改，如果周期内执行多次，则每次都是增加。
这种需求，就可以分解步骤。
1。提供不同周期的解析函数，比如每个季度、周、年、月，给当前时间，要能知道周期的开始时间和结束时间。
2.周期内频次作为维度，周期内单次和周期内多次。
3.抽象 api，比如周期内是否有该模板的数据生成、按周期查询数据、给定时间查询适配范围内的数据。
4.根据 抽象出的 api，选择使用数据结构：即选择保存周期类型、周期频次、周期开始结束时间，这样能满足大多数场景。

上面是过程分解，如果业务复杂了，还可以抽象出不同的对象模型，比如聚合商品和单个商品，可以让聚合商品继承单个商品，重写商品的行为。

总的来说，就是自上而下的结构化分解 + 自下而上的模型化分析。

附上一片非常好的博客：复杂业务代码要怎么写

最后

以上就是幽默热狗为你收集整理的业务代码应该怎么写的全部内容，希望文章能够帮你解决业务代码应该怎么写所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。