MVC itself isn&#x27;t a <i>tool of craft</i>; it&#x27;s an <i>ontology</i> for talking about code. That is, there&#x27;s no system that is or is not MVC; MVC is a guide for <i>mentally modelling a system</i>. It&#x27;s a way to distinguish parts of a continuous whole by drawing imaginary lines, like between having a &quot;brain&quot; vs. a &quot;mind&quot;, or between having a &quot;state&quot; vs. a &quot;government&quot;, or between various species of plant or animal. They&#x27;re tools to use to cluster the various actions of messy systems into well-known, recognizable <i>clumps</i>, and assign <i>labels</i> to those clumps, so that when you talk about your system&#x27;s &quot;controller&quot; and your friend talks about their system&#x27;s &quot;controller&quot;, you both can understand each-other.<p>Ontological modelling is the <i>pure</i> kind of abstraction—not the kind you reify by implementing it. There&#x27;s no &quot;MVC design pattern&quot;; all systems can be broken down into MVC. You&#x27;re never <i>not</i> implementing the &quot;MVC design pattern.&quot;<p>The <i>reason</i> people get confused is that there <i>are</i> design patterns that people implement which make an explicit distinction that looks like MVC. This has nothing to do with MVC; you haven&#x27;t &quot;implemented MVC&quot; by creating a system where all your model classes are Model classes, and all your views are Views. You&#x27;ve maybe made it easier to <i>reason</i> about your system in MVC terms, but that doesn&#x27;t get you anything unless &quot;reasoning about your system in MVC terms&quot; is something you need to do a lot, because e.g. you and your coworkers split your responsibilities that way.<p>Now, what you <i>may</i> have done instead, when you think you&#x27;ve &quot;implemented MVC&quot;, is implemented something like Hexagonal Architecture[1]: an actual <i>design pattern</i>—an idea that some-but-not-all codebases are an instance of—involving effectively inverting your &quot;app&quot; into an &quot;engine&quot; of business logic that relies on dependency-injection of engine-specified &quot;pluggable&quot; interfaces for its IO (both the out-to-the-world kind, and the in-to-its-databases and third-party-services kind.)<p>If your MVC app&#x27;s &quot;core&quot; business-logic part is a library with direct unit tests on it and so forth, and this part is useless on its own; and if you&#x27;ve got another part that <i>treats the core as a dependency</i>, and turns it into a web service or whatever else—then you&#x27;ve got Hexagonal Architecture. You&#x27;ve <i>also</i>, coincidentally, got some quite-elegantly-delineated MVC boundaries: your model and your view can&#x27;t share logic, since there&#x27;s a component boundary between them and neither one can assume anything about the other. But that&#x27;s just an <i>analytic property</i> of the code; you didn&#x27;t &quot;do MVC&quot; or even &quot;do MVC right.&quot; You just did Hexagonal Architecture, which happens to <i>make it easy to reason about your codebase in MVC terms</i>.<p>[1] <a href="http:&#x2F;&#x2F;fideloper.com&#x2F;hexagonal-architecture" rel="nofollow">http:&#x2F;&#x2F;fideloper.com&#x2F;hexagonal-architecture</a>