diff options
| author | Owen Jacobson <owen.jacobson@grimoire.ca> | 2015-12-09 20:40:42 -0500 |
|---|---|---|
| committer | Owen Jacobson <owen.jacobson@grimoire.ca> | 2015-12-09 20:40:42 -0500 |
| commit | f82d259e7bda843fb63ac1a0f6ff1d6bfb187099 (patch) | |
| tree | 502ebf27ea72cf8c6025b880bfdb35db00ce8b92 /.html/dev/rich-shared-models.html | |
| parent | 75a219a061b60bb32948b8a2b71c8ccf1dc19a62 (diff) | |
Remove HTML from the project. (We're no longer using Dokku.)
Diffstat (limited to '.html/dev/rich-shared-models.html')
| -rw-r--r-- | .html/dev/rich-shared-models.html | 187 |
1 files changed, 0 insertions, 187 deletions
diff --git a/.html/dev/rich-shared-models.html b/.html/dev/rich-shared-models.html deleted file mode 100644 index c4d167c..0000000 --- a/.html/dev/rich-shared-models.html +++ /dev/null @@ -1,187 +0,0 @@ -<!DOCTYPE html> -<html> -<head> - <title> - The Codex » - Rich Shared Models Must Die - </title> - - <link - rel='stylesheet' - type='text/css' - href='http://fonts.googleapis.com/css?family=Buenard:400,700&subset=latin,latin-ext'> - <link - rel="stylesheet" - type="text/css" - href="../media/css/reset.css"> - <link - rel="stylesheet" - type="text/css" - href="../media/css/grimoire.css"> -</head> -<body> - -<div id="shell"> - - <ol id="breadcrumbs"> - - <li class="crumb-0 not-last"> - - <a href="../">index</a> - - </li> - - <li class="crumb-1 not-last"> - - <a href="./">dev</a> - - </li> - - <li class="crumb-2 last"> - - rich-shared-models - - </li> - - </ol> - - - - <div id="article"> - <h1 id="rich-shared-models-must-die">Rich Shared Models Must Die</h1> -<p>In a gaming system I once worked on, there was a single class which was -responsible for remembering everything about a user: their name and contact -information, their wagers, their balance, and every other fact about a user -the system cared about. In a system I'm working with now, there's a set of -classes that collaborate to track everything about the domain: prices, -descriptions, custom search properties, and so on.</p> -<p>Both of these are examples of shared, system-wide models.</p> -<p>Shared models are evil.</p> -<p>Shared models <em>must be destroyed</em>.</p> -<p>A software system's model is the set of functions and data types it uses to -decide what to do in response to various events. Models embody the development -team's assumptions and knowledge about the problem space, and usually reflect -the structure of the applications that use them. Not all systems have explicit -models, and it's often hard to draw a line through the code base separating -the code that is the model from the code that is not as every programmer sees -models slightly differently.</p> -<p>With the rise of object-oriented development, explicit models became the focus -of several well-known practices. Many medium-to-large projects are built -“model first,” with the interfaces to that model being sketched out later in -the process. Since the model holds the system's understanding of its task, -this makes sense, and so long as you keep the problem you're actually solving -in mind, it works well. Unfortunately, it's too easy to lose sight of the -problem and push the model as the whole reason for the system around it. This, -in combination with both emotional and technical investment in any existing -system, strongly encourages building <code>new</code> systems around the existing -model pieces even if the relationship between the new system is tenuous at -best.</p> -<ul> -<li>Why do we share them?<ul> -<li>Unmanaged growth<ul> -<li>Adding features to an existing system</li> -<li>Building new systems on top of existing tools</li> -</ul> -</li> -<li>Misguided applications of “simplicity” and “reuse”</li> -<li>Encouraged by distributed object systems (CORBA, EJB, SOAP, COM)</li> -</ul> -</li> -<li>What are the consequences?<ul> -<li>Models end up holding behaviour and data relevant to many applications</li> -<li>Every application using the model has to make the same assumptions</li> -<li>Changing the model usually requires upgrading everyone at the same time</li> -<li>Changes to the model are risky and impact many applications, even if the - changes are only relevant to one application</li> -</ul> -</li> -<li>What should we do instead?<ul> -<li>Narrow, flat interfaces</li> -<li>Each system is responsible for its own modelling needs</li> -<li>Systems share data and protocols, not objects</li> -<li>Libraries are good, if the entire world doesn't need to upgrade at the - same time</li> -</ul> -</li> -</ul> -<p>It's easy to start building a system by figuring out what the various nouns it -cares about are. In the gambling example, one of our nouns was a user (the guy -sitting at a web browser somewhere), who would be able to log in, deposit -money, place a wager, and would have to be notified when the wager was -settled. This is a clear, reasonable entity for describing the goal of placing -bets online, which we could make reasonable assumptions about. It's also a -terrible thing to turn into a class.</p> -<p>The User class in our gambling system was responsible for all of those things; -as a result, every part of the system ended up using a User object somewhere. -Because the User class had many responsibilities, it was subject to frequent -changes; because it was used everywhere, those changes had the capability to -break nearly any part of the overall system. Worse, because so much -functionality was already in one place, it became psychologically easy to add -one more responsibility to its already-bloated interface.</p> -<p>What had been a clean model in the problem space eventually became one of a -handful of “glue” pieces in a <a href="http://www.laputan.org/mud/mud.html#BigBallOfMud">big ball of -mud</a> program. The User -object did not come about through conscious design, but rather through -evolution from a simple system. There was no clear point where User became -“too big”; instead, the vagueness of its role slowly grew until it became the -default behaviour-holder for all things user-specific.</p> -<p>The same problem modeling exercise also points at a better way to design the -same system: it describes a number of capabilities the system needed to be -able to perform, each of which is simpler than “build a gaming website.” Each -of these capabilities (accept or reject logins, process deposits, accept and -settle wagers, and send out notification emails to players) has a much simpler -model and solves a much more constrained of problem. There is no reason the -authentication service needs to share any data except an identity with the -wagering service: one cares about login names, passwords, and authorization -tickets while the other cares about accounting, wins and losses, and posted -odds.</p> -<p>There is a small set of key facts that can be used to correlate all of pieces: -usernames, which uniquely identify a user, can be used to associate data and -behaviour in the login domain with data and behaviour in the accounting and -wagering domain, and with information in a contact management domain. All of -these key facts are flat—they have very little structure and no behaviour, and -can be passed from service to service without dragging along an entire -application's worth of baggage data.</p> -<p>Sharing model classes between many services creates a huge maintenance -bottleneck. Isolating models within the services they support helps encourage -clean separations between services, which in turn makes it much easier to -understand individual services and much easier to maintain the system as a -whole. Kindergarten lied: sharing is <em>wrong</em>.</p> - </div> - - - -<div id="comments"> -<div id="disqus_thread"></div> -<script type="text/javascript"> - /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */ - var disqus_shortname = 'grimoire'; // required: replace example with your forum shortname - - /* * * DON'T EDIT BELOW THIS LINE * * */ - (function() { - var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; - dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js'; - (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); - })(); -</script> -<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript> -<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a> -</div> - - - - <div id="footer"> - <p> - - The Codex — - - Powered by <a href="http://markdoc.org/">Markdoc</a>. - -<a href="https://bitbucket.org/ojacobson/grimoire.ca/src/master/wiki/dev/rich-shared-models.md">See this page on Bitbucket</a> (<a href="https://bitbucket.org/ojacobson/grimoire.ca/history-node/master/wiki/dev/rich-shared-models.md">history</a>). - - </p> - </div> - -</div> -</body> -</html>
\ No newline at end of file |