title: Uncle Bob's Clean Code Use Case Definition
body: <h3><strong>THE</strong> Question</h3>
  <blockquote>
  <p>Do &quot;Application Detail(s)&quot; specific adapters, gateways, and the like, belong in a Use Case Interactor? Or; are Interactors meant to be clean from all adapter abstractions and only interact with Entities and return a POJO?</p>
  </blockquote>
  <p><strong>I have one question and one question only, the one above. All else is just me trying to prove my point or back up my question</strong></p>
  <p><strong>Note: What Uncle Bob calls &quot;Application Details&quot; are things like Networking, Databases, API Calls, and methods of delivery (in general)</strong></p>
  <p>So, basically...</p>
  <h3>Example(s):</h3>
  <pre><code>// This... ? (Includes a Network and a DB &quot;Application Detail&quot;)
  public function completeSale(saleDTO, networkAdapter, dbAdapter) {
      sale = transformSaleDTOToSaleEntity(saleDTO);
      transaction = null;
  
      // This is all based on there being &quot;SOME KIND OF&quot; implementation 
      // of a &quot;network&quot; and a &quot;database&quot; concept... meaning we're tightly coupled 
      // to a concept even though its implementation is hidden.
      if (netowrkAdapter &amp;&amp; dbAdapter) {
          networkResults = networkAdapter.completeTransaction(sale);
  
          if (networkResults) {
              transaction = new Transaction(sale.id);
  
              transaction.timePurchased = sale.timeCreated;
              transaction.isCompleted = networkResults.completed;
  
              dbAdapter.save(transaction);
          }
      }
  
      return transformTransactionToTransactionDTO(transaction);
  }
  
  // Or this... ? (No adapters or &quot;Application Details&quot;)
  public function completeSale(saleDTO) {
      sale = transformSaleDTOToSaleEntity(saleDTO);
      transaction = new Transaction(sale.id);
  
      transaction.timePurchased = sale.timeCreated;
      transaction.isCompleted = true;
  
      return transformTransactionToTransactionDTO(transaction);
  }
  </code></pre>
  <p>I have looked and looked. I cannot find any reference to what <strong>EXACTLY</strong> constitutes as a &quot;use case&quot;, within <a href="https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html" rel="nofollow noreferrer">Uncle Bob's Clean Code Architecture</a>. There is lots of information about how they orchestrate things, how they abstract and hide implementation, sure. But, the more common conversation(s) I tend to see about &quot;Clean Code Use Case Functions&quot; usually talk about stuff that leaves me with more questions than answers. Typically, I read about how the use cases are interactors and how they alone interact with the data layer. When I read about what a use case is (at a high level) as per Uncle Bob's definition and examples, the &quot;use cases&quot; in these interactors are basically just a UML concept of &quot;use cases&quot;. Or at least all of his blog posts and live talks seems to go over the use cases like abstract UML use cases and he never gets into the real code or concepts other than just words as a black-boxed user would know. These use cases describe an abstract set of steps that are SO abstract, one cannot really use them to just start coding right away. You have to interpret his concepts and I believe I might be failing to do so.</p>
  <p>I know how to use dependency injection with adapters or gateways in the use case function itself. This hides the implementation from the use case, and instead just calls the function name from an interface. But, technically the use case in the interactor function now always must check for the adapter in question and then fire the interface function. So... the use case kinda &quot;knows&quot; about the &quot;application details&quot;... doesn't it? It doesn't know the implementation but it still needs to ask, &quot;are you there, adapter? If so, do x&quot;.</p>
  <p>I have heard talk of &quot;Uncle Bob's Use Cases&quot; reading like a written sentence (almost) due to the high level of abstraction. But yet, I don't know how you could do that if you had to include &quot;Application Details&quot; in your use case interactor method. I have yet to see anyone mention what level or scope of &quot;Application Detail&quot; specific code, lands in these use case interactor methods. Do we use adapters via dep-injection here and make fetch calls that return from the API calling function as a POJO? Or is it highly inappropriate to call &quot;Application Detail&quot; specific functionality in the interactor methods?</p>
  <p>I am trying not to be specific by saying that the adapters are injected via &quot;constructor&quot; or &quot;method injection&quot; since all languages can use Clean Code, supposedly. But, all languages do not contain interfaces/classes. Anyway...</p>
  <p>I noticed that Uncle Bob's UML use cases always include things like &quot;Update cart&quot; or &quot;Complete transaction&quot;. So my assumption was that he is injecting the adapter into the use case and simply calling a function like &quot;completeTransaction&quot;. To this, I could imagine him saying,</p>
  <blockquote>
  <p>&quot;we don't care that there is a network call to be made, we just ask if there is a network adapter present in the parameter list and if so, call the function we require via the interface. A function called <code>completeTransaction</code>&quot;.</p>
  </blockquote>
  <p>It doesn't matter what the implementation of the <code>completeTransaction</code> function is to the use case function, it just calls the function name inside the adapter and lets the adapter worry about the implementation and the requirement of the function name.</p>
  <p>That all being said... now I am tightly coupled to needing &quot;at least 1 Network Adapter&quot;, which means my use case function both &quot;knows about the network adapter&quot; but &quot;doesn't care about what it's up to&quot;.</p>
  <p>Uncle Bob says:</p>
  <blockquote>
  <p>&quot;You’ll be able to run your tests without delay. You’ll be able to defer decisions about the UI. You’ll be able to test business rules without the UI present. That kind of flexibility and decoupling always speeds you up.&quot;</p>
  </blockquote>
  <p>However, if I include adapters or gateways that use &quot;Application Detail&quot; specific libraries and or classes, then my tests are immediately blocked by needing to start mocking that service. If I started with a use case that used 4 different &quot;Application Detail&quot; specific service(s) (i.e. network call, DB, notification system, and state update) then I would start by immediately being blocked by 4 mocked services...</p>
  <p>How does this speed us up and let us use TDD? <em><strong>It's pretty hard to drive your development with tests when each test starts by being blocked multiple ways</strong></em>.</p>
  <h3>My Assumption</h3>
  <h3><em>(what I came to have validated or corrected by asking this question, this isn't my question...)</em></h3>
  <p>I should not be using anything related to any &quot;Application Detail&quot; (such as Network calls, Databases, etc) within a use case no matter how abstract the function seems to be. I should only have 100% business logic in my use case interactors and when I return a POJO from my use case function, the controller that called the use case should then do &quot;Application Detail&quot; specific functionality. I think perhaps Uncle Bob is wanting us to make the domain-level use case functions only interact with Entities and Business Objects in the next layer down (Data), rather than doing anything with injected adapters and controllers. If you remove all non-business-logic-related concepts from your use case, then you are freed up to test without mocking and use these Use Case Function(s) more throughout your codebase, or other codebases in the future (with similar domain knowledge)</p>
  <h3>What Keeps Confusing Me</h3>
  <p>UML Use Cases always depict an abstract wording of a concept that requires an Application Detail to accomplish (it seems). Example:</p>
  <ol>
  <li>Browse product offerings</li>
  <li>Select items for purchase</li>
  <li>Provide payment instructions</li>
  <li>Provide shipping instructions</li>
  <li>Complete transaction</li>
  </ol>
  <p>To me, the 5th step 100% requires a network connection, models, transformation abilities, and so on. So, how is it helpful or easy to test (as in TDD) if my fifth step of this use case is to do something like <code>networkAdapter.completeTransaction(transactionDTO)</code>. Again, as I said, I would have to them mock the network calls and worry about the following conditions: &quot;is there a network connection?&quot;, or &quot;is the network on an expensive connection?&quot;.</p>
  <p>Also, doesn't it change the use case to include the Network Adapter into a use case function? For example, the following could change:</p>
  <ol>
  <li>Check remote API for update</li>
  <li>Compare against database copy</li>
  <li>Change detected, update business object</li>
  <li>Save in DB</li>
  <li>Show on view</li>
  </ol>
  <p>to now be:</p>
  <ol>
  <li>Is there a network adapter available?</li>
  <li>If so, then get from remote API</li>
  <li>Is there a database adapter available?</li>
  <li>If so, then get from DB</li>
  <li>Compare remote copy against DB copy</li>
  <li>Change detected, update business object</li>
  <li>Is a database adapter available?</li>
  <li>If so, save in DB</li>
  <li>Are view controller model(s) available?</li>
  <li>If so, show on view</li>
  </ol>
  <p>From this example, you can see that it's really unclear how to handle the edge case &quot;I have a network connection, but no DB present&quot;.</p>
  <h3>Lastly</h3>
  <h3><em>(also not my question, just more possible evidence to build my case)</em></h3>
  <p>If I include &quot;Application Detail&quot; specific invocations in my use case functions, and I want to use this business logic on multiple front-ends, then suddenly things become too crazy. Let's say I am using a language (like C#) that can code to use several different viewing devices (i.e. Windows Tablet and Windows Desktop). In this example, let's say you're on the road and have access to your local DB but no network on the tablet. Well, if you baked &quot;Application Specific&quot; invocations into your use case function, then you can't really always use that function now on all device types since desktop doesn't really care about the same level of &quot;connectedness&quot;. You can't &quot;code once, use everywhere&quot; this way. You have to now make 2 different use case functions, one that cares about network connection a lot more than the other.</p>