Correct link

_posts/2024-07-08-should-interfaces-be-asynchronous.html

@@ -270,7 +270,7 @@ <h3 id="66d0c20621ef43e5808f589a30314d6f">
         What if, instead of an external library, the <code>NameMap</code> class is part of an application's Domain Model?
     </p>
     <p>
-        In that case, you <em>could</em> define application-level interfaces as part of the Domain Model. In fact, most people do. Even so, I'd recommend that you don't, at least if you're aiming for a <a href="https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell">Functional Core, Imperative Shell</a> architecture, a <a href="/2018/11/19/functional-architecture-a-definition">functional architecture</a>, or even a <a href="/2013/12/03layers-onions-ports-adapters-its-all-the-same">Ports and Adapters</a> or, if you will, <a href="/ref/clean-architecture">Clean Architecture</a>. The interfaces that exist only to support testing are application concerns, so keep them out of the Domain Model and instead define them in the Application Model.
+        In that case, you <em>could</em> define application-level interfaces as part of the Domain Model. In fact, most people do. Even so, I'd recommend that you don't, at least if you're aiming for a <a href="https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell">Functional Core, Imperative Shell</a> architecture, a <a href="/2018/11/19/functional-architecture-a-definition">functional architecture</a>, or even a <a href="/2013/12/03/layers-onions-ports-adapters-its-all-the-same">Ports and Adapters</a> or, if you will, <a href="/ref/clean-architecture">Clean Architecture</a>. The interfaces that exist only to support testing are application concerns, so keep them out of the Domain Model and instead define them in the Application Model.
     </p>
     <p>
         <img src="/content/binary/ports-and-adapters-dependency-graph-2.png" alt="Ports and Adapters diagram, with arrows pointing inward.">