6 Handling external dependencies and infrastructure

Software systems rarely exist in isolation; they often interact with databases for data persistence or web services from external companies or internal teams. A significant challenge in software design is preventing our code from being contaminated by these outside details.

You may wonder why this is a problem. There are a few reasons to protect your domain from external influences. First, they can impede your ability to replace a component with something simpler, which would facilitate testing. For instance, if you lack a layer between the code that accesses an external web service and your domain logic, it becomes difficult to test the domain logic in isolation.

Second, without encapsulation, your code becomes tightly coupled to the data structures and abstractions of third-party APIs. Many libraries are not particularly stable and undergo frequent changes. You don’t want minor updates to those libraries affecting numerous places in your code.

6.1 Separate infrastructure from the domain code

6.1.1 Do you need an interface?

6.1.2 Hide details from the code, not from the developers

6.1.3 Changing the infrastructure someday: Myth or reality?

6.1.4 Example: Database access and the message bot

6.2 Use the infrastructure fully

6.2.1 Do your best not to break your design

6.2.2 Example: Cancelling an enrollment

6.3 Only depend on things you own

6.3.1 Don’t fight your frameworks

6.3.2 Be aware of indirect leakage

6.3.3 Example: Message bot

6.4 Encapsulate low-level infrastructure errors into high-level domain errors

6.4.1 Example: Handling exceptions in SDKBot