[300bps]

When you have something at the bottom of a dependency chain that is quite deep (with any enterprisey project), you have to recompile all consumers and therefore everything that depends on them and so forth. A single line change means you end up compiling the entire system on top of it.

This just isn't true at all. Even in COM days it wasn't true. With COM, if you preserved binary compatibility you didn't need to re-compile a client if you compiled a new version of a DLL it calls. In .NET it's even more forgiving. Sure, if you change something major like delete a bunch of properties that are used in the client then you have to recompile the client. But in many cases you don't.

Beyond this, if your architecture has 200 DLLs, it might be completely appropriate but it is a suspect architecture. I manage a .NET project that trades $4 billion of fixed income instruments per day, interfaces to three trading platforms, interfaces to 13 custodial systems and 7 different data providers. It uses about 25 DLLs and is quite manageable.

Finally, how often do you recompile a DLL that is "quite deep" in the dependency chain? Generally, such low-level DLLs should do very little. For example, maybe it's appropriate to change them if you change from Oracle to SQL Server but how often would that happen?

[d0]

COM is different. The interfaces are well defined between components and processes.

In .Net, any contracts that break between layers in your dependency chain force a rebuild of all layers above it. This is not unusual in .Net projects as the components are bound at runtime.

There are not 200 DLLs - there are 200Mb of DLLs. Total count is 122 DLLs.

This particular beast handles integrations with over 100 systems using vastly different non COTS integration methods, has over 2500 tables, 950 domain objects, 400 controllers, 45 databases, 200 API endpoints, async background processing and piles of MSMQ queues. Data volume is terabytes. It's a behemoth and it's been around for 33 years in various forms.

If you, as we do, change architectural components and APIs, dependencies are broken. The main case for this is when we version our API. We have up to 3 API versions in production. When someone introduces a new API version, the oldest is deprecated and all the historic versions are ported to the newest internal API. This is where it becomes dependency hell.

However it's a fine way to avoid technical debt!