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