Home/ Questions/Q 3318560
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T22:43:13+00:00

To be perfectly clear, I do not expect a solution to this problem. A

  • 0

To be perfectly clear, I do not expect a solution to this problem. A big part of figuring this out is obviously solving the problem. However, I don’t have a lot of experience with well architected n-tier applications and I don’t want to end up with an unruly BLL.

At the moment of writing this, our business logic is largely a intermingled ball of twine. An intergalactic mess of dependencies with the same identical business logic being replicated more than once. My focus right now is to pull the business logic out of the thing we refer to as a data access layer, so that I can define well known events that can be subscribed to. I think I want to support an event driven/reactive programming model.

My hope is that there’s certain attainable goals that tell me how to design these collection of classes in a manner well suited for business logic. If there are things that differentiate a good BLL from a bad BLL I’d like to hear more about them.

As a seasoned programmer but fairly modest architect I ask my fellow community members for advice.

Edit 1:

So the validation logic goes into the business objects, but that means that the business objects need to communicate validation error/logic back to the GUI. That get’s me thinking of implementing business operations as objects rather than objects to provide a lot more metadata about the necessities of an operation. I’m not a big fan of code cloning.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Kind of a broad question. Separate your DB from your business logic (horrible term) with ORM tech (NHibernate perhaps?). That let’s you stay in OO land mostly (obviously) and you can mostly ignore the DB side of things from an architectural point of view.

    Moving on, I find Domain Driven Design (DDD) to be the most successful method for breaking a complex system into manageable chunks, and although it gets no respect I genuinely find UML – especially action and class diagrams – to be critically useful in understanding and communicating system design.

    General advice: Interface everything, build your unit tests from the start, and learn to recognise and separate the reusable service components that can exist as subsystems. FWIW if there’s a bunch of you working on this I’d also agree on and aggressively use stylecop from the get go 🙂

    • 0