Skip to content

Instantly share code, notes, and snippets.

@jeremy-w

jeremy-w/The A Word.html

Created August 12, 2013 01:42
Show Gist options
  • Save jeremy-w/6207743 to your computer and use it in GitHub Desktop.
Save jeremy-w/6207743 to your computer and use it in GitHub Desktop.
Download ZIP
Notes on a Bob Martin talk. Introduces Ivar Jakobson's BIE model and puts MVC in its place (GUIs only).
Raw
The A Word.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1187.39">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; text-indent: 18.0px; font: 14.0px Cochin}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; text-indent: 18.0px; font: 14.0px Cochin; min-height: 17.0px}
span.Apple-tab-span {white-space:pre}
</style>
</head>
<body>
<p class="p1">Bob Martin at SCMC (Software Craftsmanship MC) in October 2011.</p>
<p class="p2"><br></p>
<p class="p1"><a href="https://vimeo.com/30083598">https://vimeo.com/30083598</a></p>
<p class="p2"><br></p>
<p class="p1">---</p>
<p class="p2"><br></p>
<p class="p1">Notes by Jeremy W. Sherman, <a href="https://jeremywsherman.com/">https://jeremywsherman.com/</a>.</p>
<p class="p1">2013-08-10.</p>
<p class="p1">---</p>
<p class="p2"><br></p>
<p class="p1">Ivar Jakobson.</p>
<p class="p2"><br></p>
<p class="p1">MVC just for GUIs. Many models, each with its own view (displays model), each with its own controller (mouse/keyboard).</p>
<p class="p2"><br></p>
<p class="p1">---</p>
<p class="p2"><br></p>
<p class="p1">What is your system architecture? “Rails with Devise on Postgres”. That’s not an architecture! It’s a toolset.</p>
<p class="p2"><br></p>
<p class="p1">Architecture reflects domain, not delivery mechanism.</p>
<p class="p2"><br></p>
<p class="p1"><span class="Apple-converted-space"> </span>- Library</p>
<p class="p1">- Home</p>
<p class="p1">- Office</p>
<p class="p2"><br></p>
<p class="p1">not</p>
<p class="p2"><br></p>
<p class="p1">- Brick</p>
<p class="p1">- Steel</p>
<p class="p1">- Concrete</p>
<p class="p2"><br></p>
<p class="p1">---</p>
<p class="p2"><br></p>
<p class="p1">Software architecture is embodied in use cases.</p>
<p class="p2"><br></p>
<p class="p1"><b>Use case: input, output, flow - algorithm.</b></p>
<p class="p1"><span class="Apple-tab-span"> </span>- Might also have several error-out pathways.</p>
<p class="p2"><br></p>
<p class="p1">Jakobson called these “controls”. Martin calls them “interactors”. Should be <b>delivery mechanism independent</b> – specify data in out, not how it gets in out.</p>
<p class="p2"><br></p>
<p class="p1"><b>Entity objects contain universal business rules.</b></p>
<p class="p1"><span class="Apple-tab-span"> </span>- Reusable across applications!</p>
<p class="p2"><br></p>
<p class="p1"><b>Interactors contain algorithms for the app-specific use cases.</b></p>
<p class="p1"><span class="Apple-tab-span"> </span>- Use entity objects to get their work done.</p>
<p class="p2"><br></p>
<p class="p1">With interactors and entity objects, we have an entirely functional application without:</p>
<p class="p2"><br></p>
<p class="p1">- GUI</p>
<p class="p1">- DB</p>
<p class="p1">- Web</p>
<p class="p1">- Any fixed interface!</p>
<p class="p2"><br></p>
<p class="p1">This is a dream for testing.</p>
<p class="p2"><br></p>
<p class="p1">---</p>
<p class="p2"><br></p>
<p class="p1">But do eventually need to deliver the system to the Real World. (Example: Using the Web as delivery mechanism.)</p>
<p class="p2"><br></p>
<p class="p1">Jakobson’s final object type: <b>Boundary objects</b> – between UI and Interactors.</p>
<p class="p2"><br></p>
<p class="p1">Web UI builds a simple input data structure (boundary object) and feeds it to the interactor.</p>
<p class="p2"><br></p>
<p class="p1">Interactor builds a response data structure (boundary object) and passes it back to the Web interface.</p>
<p class="p2"><br></p>
<p class="p1">Model–View–Presenter:</p>
<p class="p2"><br></p>
<p class="p1">- Presenter takes data out of boundary object (GUI model), converts to strings for Web display, hands that to the view.</p>
<p class="p1">- View gets webbified data structures (NOT BUSINESS OBJECTS) and renders them.</p>
<p class="p2"><br></p>
<p class="p1"><b>Moving Web to thick (mobile) client is just replacing the delivery mechanism!</b></p>
<p class="p2"><b></b><br></p>
<p class="p1">---</p>
<p class="p2"><b></b><br></p>
<p class="p1">Where’s the database? The objects that know about the database are the Interactors, because they know about transactions.</p>
<p class="p2"><br></p>
<p class="p1">- In those notion the DB is to service <b>many</b> applications, not just one.</p>
<p class="p1">- This is far different from most of the applications I am used to.</p>
<p class="p1">- DB schema is lowest common denominator.</p>
<p class="p1">- Its schema is defended by DBAs, who alter it to speed up some applications over others.</p>
<p class="p1">- Schema makes no sense for a single app, unlike entities and interactors.</p>
<p class="p2"><br></p>
<p class="p1">So need a translation layer schema &lt;=&gt; entities.</p>
<p class="p2"><br></p>
<p class="p1">- Models in Rails are not business objects!</p>
<p class="p1">- They are representatives of the schema.</p>
<p class="p1">- Do not put business objects in there – this warps the rules.</p>
<p class="p2"><br></p>
<p class="p1"><b>Interactors know of the app DB. Start, rollback, etc. Talks to boundary layer that forks over entity objects as needed.</b> (This is the Store in BNR’s MVCS notion, but better segregated.)</p>
<p class="p2"><br></p>
<p class="p1">This interface lets you replace database with test doubles. <b>No tests on production data. Ever.</b></p>
<p class="p2"><br></p>
<p class="p1">---</p>
<p class="p2"><br></p>
<p class="p1">Surrendered architecture to framework developers.</p>
<p class="p2"><br></p>
<p class="p1">Examples are utterly committed to the framework. You read those examples. You accidentally swallow the kool-aid.</p>
<p class="p2"><br></p>
<p class="p1">Don’t trust the framework! Beware Other People’s Software – use it as a tool, not as a faux architecture.</p>
<p class="p2"><br></p>
<p class="p1">Pull down gems once you have an application and need to support the UI. Don’t commit your core app to external libraries.</p>
<p class="p2"><br></p>
<p class="p1">Software craftsmanship: pride in your work product. What must we change so what we do is good?</p>
<p class="p2"><br></p>
<p class="p1">Time to address the notion of <b>architecture</b>. Agile was wrong: We do need architecture. Tests alone are not enough. You need an hour, a day, two days (not much more…) of thought to avoid coupling, cohesion, generate SOLID code….</p>
<p class="p2"><br></p>
<p class="p1">---</p>
<p class="p2"><br></p>
<p class="p1">Examples of this architecture: Fitnesse. See <a href="http://fitnesse.org/">http://fitnesse.org/</a> and <a href="https://github.com/unclebob/fitnesse">https://github.com/unclebob/fitnesse</a>.</p>
<p class="p2"><br></p>
<p class="p1"><b>“A Ruby teams fails when it types ‘Rails’ before they have thought through their use cases. If it’s one of the last things they type, fine, but if it’s one of the first, they’ve lost.”</b></p>
<p class="p2"><br></p>
<p class="p1">A good architecture lets you delay details like persistence till later. You don’t have to (you might be building vertical slices), but the option is there.</p>
<p class="p2"><br></p>
<p class="p1">The language used unfortunately must be determined quite early.</p>
<p class="p2"><br></p>
<p class="p1"><b>Effectively, you write your app as a gem (jar file, DLL, whatever), and then the web system, the database, whatever, is just a plugin to the application.</b></p>
<p class="p2"><br></p>
<p class="p1">It doesn’t matter when you fire up Rails, really, as long as it’s not the very first things you do. What you do want to make sure is that the isolation is built in. If you need a webpage up by the end of the first iteration, fine, but don’t do so by using the framework first. Build the use case, the separation, then fire up a Rails app that calls into the interactors to bring up the page.</p>
<p class="p2"><br></p>
<p class="p1">Audience member points out that this is less of an issue in .NET – it’s standard to have a business-specific DLL with its own fast tests, and then you lash that together with a UI.</p>
<p class="p2"><br></p>
<p class="p1">Jakobson hand-waved about entities; Eric Evans’ Domain-Driven Design book goes into great detail on them, but in a way compatible with Jakobson’s boundary-interactor-entity model.</p>
</body>
</html>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment