Question

I look around and see some great snippets of code for defining rules, validation, business objects (entities) and the like, but I have to admit to having never seen a great and well-written business layer in its entirety.

I’m left knowing what I don’t like, but not knowing what a great one is.

Can anyone point out some good OO business layers (or great business objects) or let me know how they judge a business layer and what makes one great?

Thanks

Answer 1

Good business layers have been designed after a thorough domain analysis. If you can capture the business’ semantics and isolate it from any kind of implementation, whether that be in data storage or any specific application (including presentation), then the logic should be well-factored and reusable in different contexts.

Just as a good database schema design should capture business semantics and isolate itself from any application, a business layer should do the same and even if a database schema and a business layer describe the same entities and concepts, the two should be usable in separate contexts–a database schema shouldn’t have to change even when the business logic changes unless the schema doesn’t reflect the current business. A business layer should work with any storage schema provided that it’s abstracted via an intermdiate layer. For example, the ADO.NET Entity framework lets you design a conceptual schema which maps to the business layer and has a separate mapping to the storage schema which can be changed without recompiling the business object layer or conceptual layer.

If a person from the business side of things can look at code written with the business layer and have a rough idea of what’s going on then it might be a good indication that the objects were designed right–you’ve succesfully conveyed a solution in the problem domain without obfuscating it with artifacts from the solution domain.