Reusing business logic layer in multiple applications

Question

I have seen some people asking about sharing business logic with more than one application, and answers generally discuss putting it in a class library. I'm fine with that, but usually the examples have two applications, and they just make a class library with the business logic they both care about, and both applications share that library.

In my case, I have several component types (not sure if that is the right term - for example I have modems, users, and telephony services). I also have several applications, each of which may use multiple component types. So application A might need modems and telephony services but not users, application B might need modems and users, and application C might need only the telephony services.

Would it be better to have one big business layer class library with all types, or should I have a library for each component type?

As an example, say I have the three components listed above, and data access can be done either via SQL Server or a proxy application.

Option 1: A single class library for all business logic in the company

MyCompany.BusinessLogic (contains business logic classes for modems, agents, telephony, ...)
MyCompany.Data.SQLServer (contains classes for accessing modem, agent, telephony data from SQL Server)
MyCompany.Data.Proxy (contains classes for accessing modem, agent, telephony data from the proxy application)
Modems.Communication (contains classes that know the protocol for communicating with a modem)
Telephony.Communication (contains classes that know the protocol for communicating with a telephony server)

The downside to this is whenever there is a change to the modem logic or data, we have to rebuild and deploy a library used by applications that don't even care about modems.

Option 2: Each component in its own class library

Modems.BusinessLogic
Modems.Data.SQLServer
Modems.Data.Proxy
Modems.Communication
Agents.BusinessLogic
Agents.Data.SQLServer
Agents.Data.Proxy
Telephony.BusinessLogic
Telephony.Communication
Telephony.Data.SQLServer
Telephony.Data.Proxy

This way, applications can pick and choose which libraries they want. And if one changes, only applications that care about that component type would need to change. I worry, though, about having to maintain too many little libraries. The Modems.Data.SQLServer library, for example, might just have one class in it.

So, which method is more commonly used? Or is there some other way that I'm missing?

Answer 1

In my experience, if you have a use case where you want to pick different areas of your code for reusage, as shown in your example, it is preferable to have small, independent components, even if some of them might contain just one class. You already mentioned a very good reason for this in your text: restricting the impacts of change.

However, there are some things to consider:

• if some of the components are tightly coupled to each other, so you actually cannot really reuse one of them without the other, then putting them in different libs may become counter productive

• the required effort for configuration management will increase. This includes stuff like setting up projects, managing version numbers, packaging, documentation etc. This can be mitigated by having some standards in your project and automating things, for example, by creating scripts

• depending on the programming language and environment, having lots of different components can increase the compile times. In the .Net environment, in my experience, this typically starts to happen when you have more than 70 to 100 different libs to include as projects (but not as precompiled assemblies, that number is quite higher). This documentation for NDepend discusses the problem and gives some suggestions how to deal with it.

• for single, self-contained classes, it can be sufficient to reuse them by direct linkage, as lightweight components, instead of creating a full-blown class-library around them.

So in the end, it is a trade-off: lots of independent small libs can be beneficial, but you don't get this for free. You will have to find out by yourself where the sweet spot is for your specific type of projects.