3 ms·

> Many people will argue that not using a framework means write everything yourself. This is a false dichotomy. We can use libraries and frameworks just fine. .

> Many people will argue that not using a framework means write everything yourself. This is a false dichotomy. We can use libraries and frameworks just fine. ... > But we should give them a clear, and well-isolated place in our project. ... There's an excellent, if older, presentation called "Architecture, the Lost Years" that addresses exactly this problem and gives very specific, actionable guidance on how to solve it: https://www.youtube.com/watch?v=WpkDN78P884 https://www.youtube.com/watch?v=WpkDN78P884 But how to pull off this decoupling? The answer is both obvious and surprising. Define a boundary. On one side is the framework. On the other side is your code. Through the boundary, only dumb data structure can pass. JSON works. So do structs. So does XML. The point is that these are behaviorless blobs of data. This buys you a lot. You can run your application completely detached from the network, a database, and other expensive dependencies. So testing becomes much simpler and easier. And of course, you can replace the framework by writing new boundary code. The other big lesson has something to do with why frameworks get added to a project in the first place. When designing a system, the goal should be to defer major decisions for a long as possible. That's when the best information is available. Sometimes you can just defer until the point becomes moot, which is a major win. Reaching for a framework before being forced to do so sets up the kind of situation the author is talking about.

googlryas 4y ago
Isn't the problem here that your decouple framework requires data X,Y, and Z in the message across the boundary, so you plumb that data through right near boundary where the request is made. But later on, you want to switch out a different framework, but that framework requires U, V, W, X, f(y), and Z. So even on your apps side of the boundary layer, you still formatted your code and data flow to support the single framework you started with.
- fuzzy2 4y ago
  If your message contains framework-dependent data, it wasn’t decoupled. For example, in a typical web API, all the stuff concerning HTTP endpoints, JSON, OpenID Connect or whatever should be entirely separate from your domain logic. I’ve been doing this for years and it is very feasible. Do you still have to write code where the framework dictates its structure? Absolutely. That’s the decoupling layer. Do you have to change this layer if you upgrade or switch frameworks? Also yes. However, you don’t have to touch the application core.
  - berkes 4y ago
    I too have been doing the same. It's surprisingly simple and elegant. I prefer 'ports and adapters, aka hexagonal architecture', but there are many alternatives. This is what prompted me to write this article: the simplicity, elegance and maintainability of those codebases that had domain logic separated from delivery and storage mechanisms.
hamandcheese 4y ago
“When designing a system, the goal should be to defer major decisions for a long as possible.” I noticed that I tend to do this, but never knew it was a legit strategy.

googlryas 4y ago

Isn't the problem here that your decouple framework requires data X,Y, and Z in the message across the boundary, so you plumb that data through right near boundary where the request is made. But later on, you want to switch out a different framework, but that framework requires U, V, W, X, f(y), and Z. So even on your apps side of the boundary layer, you still formatted your code and data flow to support the single framework you started with.

fuzzy2 4y ago
If your message contains framework-dependent data, it wasn’t decoupled. For example, in a typical web API, all the stuff concerning HTTP endpoints, JSON, OpenID Connect or whatever should be entirely separate from your domain logic. I’ve been doing this for years and it is very feasible. Do you still have to write code where the framework dictates its structure? Absolutely. That’s the decoupling layer. Do you have to change this layer if you upgrade or switch frameworks? Also yes. However, you don’t have to touch the application core.
- berkes 4y ago
  I too have been doing the same. It's surprisingly simple and elegant. I prefer 'ports and adapters, aka hexagonal architecture', but there are many alternatives. This is what prompted me to write this article: the simplicity, elegance and maintainability of those codebases that had domain logic separated from delivery and storage mechanisms.

hamandcheese 4y ago

“When designing a system, the goal should be to defer major decisions for a long as possible.” I noticed that I tend to do this, but never knew it was a legit strategy.