architecture - 我应该如何实现我的业务逻辑层？

Question

假设我有一个 80% 复杂业务逻辑和 20% CRUD 的应用程序，反之亦然。

在过去，我使用过某种命令模式，并且有类似ComplexFooCMDor的类，EvenMoreComplexBarCMD但总是以一堆InsertFoo,UpdateFoo和DeleteFoo以及SelectFoosCMD一些UpdateSomeValuesOfFooor结尾SelectSomeFoos。所有这些都生活在 BLL 中。

最近在不太复杂的业务逻辑应用程序中，我使用了带有类的服务模式，FooService但这些类也包含预期的insertFoo,updateFoo和selectSomeFoo. 在每个服务上都有这些方法，甚至有只存在将这些方法暴露给表示层的服务，感觉就像很多样板代码。

是否有适合 CRUD 部分和应用程序其余部分的模式，或者我应该为应用程序的不同部分使用不同的模式？

Answer 1

我不会认为 CRUD 是业务规则。

我不确定是否有这样的规则模式，例如“为首选客户提供百分比折扣，这是他们今年迄今为止的销售量的函数”或“不要在用户界面中为公司地址为的客户显示此选项从这个国家列表中"。

业务规则并不总是那么整洁。

Answer 2

我强烈建议阅读行为驱动开发。我认为它将引导您朝着正确的方向前进。

我读过的关于这个主题的最好的书是The RSpec Book，但是如果你对很多以 Ruby 为中心的例子感到厌烦，你可能想看看基于你最喜欢的语言的其他资源。

简而言之，您的问题的答案是：让您的测试指导您的架构，让您的应用程序所需的行为指导您的测试。