如何设计业务逻辑层

Question

非常清楚地说，我并不期望这个问题的解决方案。解决这个问题的很大一部分显然就是解决问题。但是，我在架构良好的n层应用程序方面没有太多经验，我不想以一个难以驾驭的BLL结束。

在写这篇文章的时候，我们的业务逻辑在很大程度上是一个交织在一起的球。具有相同业务逻辑的银河系间混乱的依赖关系被多次复制。我现在的重点是将业务逻辑从我们称为数据访问层的东西中提取出来，这样我就可以定义可以订阅的众所周知的事件。我想我想支持事件驱动/反应式编程模型。

我希望有一些可以达到的目标，告诉我如何以一种适合业务逻辑的方式设计这些类的集合。如果有什么东西可以区分好的BLL和坏的BLL，我想听到更多关于它们的信息。

作为一名经验丰富的程序员，但也是一名相当谦虚的架构师，我向我的社区成员寻求建议。

编辑1：

因此，验证逻辑进入业务对象，但这意味着业务对象需要将验证错误/逻辑传回GUI。这让我开始考虑将业务操作实现为对象，而不是对象，以提供更多关于操作必要性的元数据。我不是代码克隆的狂热粉丝。

Answer 1

这是一个宽泛的问题。使用ORM技术(也许是NHibernate？)将DB与业务逻辑(可怕的术语)分开。这让你在很大程度上(显然)停留在OO领域，并且从架构的角度来看，你基本上可以忽略DB方面的事情。

继续下去，我发现领域驱动设计(DDD)是将复杂系统分解为可管理的块的最成功的方法，尽管它没有得到尊重，但我真的发现它在理解和沟通系统设计方面非常有用。

一般建议:接口一切，从一开始就构建你的单元测试，并学会识别和分离可以作为子系统存在的可重用服务组件。顺便说一句，如果你们中有一群人在做这件事，我也会同意，并从一开始就积极使用stylecop :)

Answer 2

我发现领域驱动设计的一些实践在将复杂的业务逻辑拆分成更易管理/可测试的块时非常优秀。

查看以下链接中的示例代码：

http://dddpds.codeplex.com/

DDD专注于你的域层或BLL，如果你喜欢，我希望它能有所帮助。

Answer 3

我们只是从架构的角度来讨论这个问题，它的主旨是“抽象，抽象，抽象”。

您可以使用EBC进行自上而下的设计，并将接口定义传递给程序员团队。使用像这样的方法论(或任何其他可视化技术)可视化依赖关系可以防止您在项目中的任何地方复制业务逻辑。