Crafting Code Podcast

~/podcast

$ cd episodes/022-fending-off-frameworks

~/podcast/episodes/022-fending-off-frameworks $ ls -1a

. .. episode-summary.txt get-mp3.sh

~/podcast/episodes $ cat episode-summary.txt

Software frameworks are so useful we can hardly imagine working without them. Yet they have an insidious tendency to invade, corrupt, and wrest control away from us. In this episode, your hosts discuss the good and bad of frameworks then offer some suggestions for keeping them at arm's length.

Timestamps

[00:00:00] Host introductions. What is a framework? Code that calls your code rather than code you call. Frameworks are important and useful.

[00:05:27] Why fend off frameworks? You can easily get too coupled. It does things TO you, not just FOR you. The framework may not continue to work for you over time.

[00:09:50] Frameworks are someone else's code: they can make changes to it. Keeping frameworks at a distance allows you to get the benefits while mitigating risk. Frameworks solve generic problems and the authors are not incentivized to solve your problems.

[00:13:16] When do you follow the framework's way of doing things vs. blazing your own trail? Is an ORM a framework? Be careful about blurring the lines between ORM models and domain entities. What if you need to upgrade your database, but the ORM doesn't support it? Frameworks bring in a set of constraints.

[00:19:14] Your system is not about controllers or views or data-access. Where do you create separations? Can you swap out the invocation flow or persistance layer? Most of your domain should be testable without the framework.

[00:22:29] Frameworks do a lot "for free (TM)", but we tend to only use a few things within a framework. GoLang doesn't compile if you aren't using it; JavaScript does tree-shaking. Dependencies are a liability. Recent(-ish) emergence of supply chain effects in software. 90% rule: the last 10% also takes 90% of the time.

[00:26:30] Service mesh is basically a framework for microservices; it is not really related to the value you're delivering. Keep your code flexible.

[00:28:11] Different communities seem to have different levels of comfort about adopting massive frameworks. Some communities / languages like GoLang seem to be a reaction to having had bad framework experiences.

[00:34:54] General concepts that help you keep frameworks at bay. Open-Closed principle, Interface Segregation, Domain Driven Design patterns (like Repository), and Hexagonal architectures. Understand what's possible! DDD anti-corruption layer.

[00:38:18] Matt applies framework abstraction to goal-setting frameworks. Keep the things that aren't important to your domain away. If you make a change in one place (postgres driver) it shouldn't affect hundreds of things. Organizational designers could take a cue from Onion architectures.

[00:42:05] Common boundaries include: database, HTTP, and front-end JavaScript. Your JavaScript front-end shouldn't have the same shapes as your back-end and database.

[00:43:38] More ways to fend off frameworks: Actor model, dependency injection, mapping layers, composition (a la unix pipes), immutable data structures. "Side effects: keep them out." DDD aggregate roots.

[00:50:41] Summary: frameworks are super useful, but also dangerous, so take care. Outro