一个 业务逻辑代码 的设计的问题

[yeqiu]

现在的项目有一个业务逻辑层，层中的每一个类（ business ）都针对一个业务模型（ model ）。

我现在有两个 business，dockBusiness （针对的 model 是 dock ）和 serviceBusiness （针对的 model 是 service ）。

现在有一段逻辑是这样的：

1. 通过 dock_id 获取 dock
2. 然后使用 dock 创建一个 service
3. 然后再根据 dock 的内容，修改 service 的某些字段。

这种情况下应该把这段代码放到哪里？感觉放在 dockBusiness 和 serviceBusiness 都不合适。

我有一个想法是创建一个新的 business （例如 dock_serviceBusiness ），但项目中这种情况很多，岂不是要创建很多这样的 business 么，这样很不优雅。

小伙伴，你们是怎么做的？

[micean]

别纠结这种问题，凭直觉~

[kkkkkrua]

dockBusiness 调用 serviceBusiness 不可以吗
//dockBusiness
1.getdock
2.serviceBusiness.create();
3.serviceBusiness.update();

[yeqiu]

@kkkkkrua #2

考虑到 business 的原子性，所以设定了 business 之间不能互相调用的规则。

只有上层（表现层，api 等）才可以调用 business 层。

[kkkkkrua]

@yeqiu #3 那调用下层的呢？
//dockBusiness
1.getdock
2.servicemapper.create();
3.servicemapper.update();

[yeqiu]

@kkkkkrua #4

那就违背了 业务逻辑集中 这一个出发点，变成一个 business 对应两个 model 了

servicebusiness 就是为了把跟 service 相关的业务逻辑集中在一起的，例如创建 service 时的价格、日志、产品等逻辑

[timethinker]

感觉你的 business 上面应该还有一个应用层吧，针对具体的用例封装这些逻辑，每一个方法都是一个独立事务，没必要复用应用层了，相反 business 可以被复用。如果是我的话直接一个 service 可能就结束了，没必要搞复杂，顺手就行了，效率才是最重要的。

[yeqiu]

@qwe520liao #6

对，目前的做法确实是在应用层调用了 busines 。
主要是 dockBusiness.getdock，serviceBusiness.create，serviceBusiness.edit 这三个方法。
这种情况下存在的问题是。
1. 进行了多次数据库操作，create 和 edit 中至少两次保存了数据，为了保证一致性，需要增加额外的事务相关的代码。
2. “然后再根据 dock 的内容，修改 service 的某些字段”这其中的逻辑也是复用的，需要封装到 business 中。

所以感觉目前的方法并不好，想看看小伙伴们都怎么处理。

[kkkkkrua]

@yeqiu #5 不管什么情况，总有都要同时调用多个 business 的，那你这个调用点在哪就写哪

[timethinker]

那我建议你最好不要把事务放到 business 上面，粒度小会影响性能，如果不考虑用例你将无法预料会被怎样调用，事务边界应该是按照某一个用例来的，而不是按照增删改查这种没有什么语义的偏技术功能性的方法。在我看来 edit 这种就是没有什么业务语义的方法（类似 update ），把它当作了偏底层的 DAO/MAPPER 来用了。

[ccde8259]

这种流程的相互支配性明显是 dock 盖过了 service 。因此设计上完全可以调转方向，依靠 dock 向 service 单向发射指令的方式实现。
具体实现可以是 dockBusiness 里面执行第二步的时候调用 fireServiceCreated(dock)。由 serviceBusiness 实现 onServiceCreate(Dock dock)方法。在第三步调用 fireServiceUpdate(dock)，由 serviceBusiness 实现 onServiceUpdate(Dock dock)方法。
中间的消息流转机制可以简单的用同步实现，也可以采用异步消息队列实现。serviceBusiness 需要对上面调用考虑是否需要补偿机制。

[yeqiu]

@ccde8259 #10

懂了，好办法