完全清楚，我不希望这个问题有解决方案。解决这个问题的很大一部分显然是解决问题。但是，我在架构良好的 n 层应用程序方面没有很多经验，我不想最终得到一个不守规矩的 BLL。
在撰写本文时，我们的业务逻辑在很大程度上是一个混合的麻线球。具有相同业务逻辑的星系间依赖关系被多次复制。我现在的重点是从我们称为数据访问层的东西中提取业务逻辑，以便我可以定义可以订阅的众所周知的事件。我想我想支持事件驱动/响应式(Reactive)编程模型。
我希望有某些可实现的目标告诉我如何以非常适合业务逻辑的方式设计这些类集合。如果有什么东西可以区分好的 BLL 和坏的 BLL，我想听听更多关于它们的信息。
作为一名经验丰富的程序员但相当谦虚的架构师，我向我的社区成员寻求建议。
编辑1:
所以验证逻辑进入业务对象，但这意味着业务对象需要将验证错误/逻辑传达回 GUI。这让我想到将业务操作作为对象而不是对象来实现，以提供更多关于操作必要性的元数据。我不是代码克隆的忠实粉丝。
最佳答案
有点宽泛的问题。使用 ORM 技术(也许是 NHibernate？)将您的数据库与您的业务逻辑(可怕的术语)分开。这让您主要(显然)留在 OO 领域，并且从架构的角度来看，您几乎可以忽略事物的 DB 方面。
继续前进，我发现领域驱动设计 (DDD) 是将复杂系统分解为可管理块的最成功方法，尽管它没有得到尊重，但我真的发现 UML——尤其是 Action 和类图——在以下方面非常有用理解和交流系统设计。
一般建议:连接一切，从一开始就构建单元测试，并学习识别和分离可以作为子系统存在的可重用服务组件。 FWIW 如果你们中有很多人在做这个，我也同意并从一开始就积极使用 stylecop :)
关于oop - 如何设计业务逻辑层，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4085805/