anchor.diff:    # Application Services used in Controller methods
     ##
   
  -  def access_service
  -    @sf_access_service ||= ::AccessService.new({registry: self})
  -    yield @sf_access_service if block_given?
  -    @sf_access_service
  +  def content_service
  +    @sf_content_service ||= ::ContentService.new({registry: self})
     end
   
     ...
  
positive.code:                   <%= image_tag("SknService-ControllerFlow.png", alt: "Flow Path", class: "huge-image") %>
  
                    <p class="lead">Using object-oriented design methodologies, we develop a domain model for our application, and encapsulate those objectives in a Domain class.</p>
                      <p>To delivery the value contained in a <strong>Domain class</strong> we wrap them in a <strong>Services class</strong>.  Which acts as an adapter to bring that value to the user.  This typically means
                         developing an html page with views and controllers to present the informational results to the user.  However, since we only delivery a package of data values to the controller interface
                         method, it is possible to serve those data values as JSON to a browser based application, like BackBone, or to a wide range of endpoints; even a PDF generator.</p>
                      <p>The core of our Application is defined in an object-oriented fashion and protected or isolated from the delivery frameworks(s) used to delivery its value to the user.
                         When changes and enhancements to the business logic are needed, we can make those changes without great concern or constraints being imposed by the delivery mechanism.  This also facilitates
                         easier upgrades of the delivery frameworks; since we have reduced the number of touch points between our application the Rails.</p>
                      <p>Services inherit directly from Domains to further shield our application from the external frameworks; this is easy to see when considering the controller.  Models on the other hand
                         need to be wrapped by Domain methods to prevent their inline introduction or leakage into the Domains.  I've chosen to go one step further and dedicate a <code class="language-ruby">&lt;context&gt;Provider</code>
                         class that wraps all the ActiveRecord IO calls, expecting it to be called by either Domain methods or Services methods.  I have considered using a Repository strategy to add more isolation and to facilitate testing.
  
negative.code:             <div class="panel-heading" role="tab" id="headingGuidance">
                  <h4 class="panel-title">
                      <a class="collapsed" role="button" data-toggle="collapse" href="#guidance" aria-expanded="false" aria-controls="headingGuidance">
                          Design Guidance: SknStrategy
                      </a>
                  </h4>
              </div>
              <div id="guidance" class="panel-collapse collapse" role="tabpanel" aria-labelledby="headingGuidance">
                  <div class="panel-body">
                      <p class="lead">DO NOT FOLLOW THE RAILS WAY.</p>
                      <p>The MVC model is a classic and used with success, as is, for many applications.  However, when the project's code-set exceeds a certain size or feature-set mix,
                        your ability to grow the codebase by adding new features and/or upgrading to the next release of Rails can be severely hampered.  This is no surprise as MVC was
                        conceived for small Web Applications.</p>
                      <p>Understanding these growth issues, it is recommended that you apply a more traditional approach to building applications that use the Web, by isolating or
                        treating Rails as a Web Interface as much as possible.</p>
                      <p>Although there are many application architectures and patterns to choose from, isolating Rails APIs yields the greatest value.  These five actions will
                        deliver that value:</p>
                      <dl class="dl-horizontal">
                        <dt>Remove from Controller</dt>
                          <dd>Create Service or UseCase classes to contain the code you would otherwise put into Rails Controller URL-Methods.</dd>
                          <dd>&nbsp;</dd>
                        <dt>Remove from Models</dt>
                          <dd>Collect all ActiveRecord invocations and methods into a one or more classes which follow the Repository or Provider pattern, suitable for dependency injection.</dd>
                          <dd>&nbsp;</dd>
                        <dt>Remove from Views</dt>
                          <dd>Limit controller instance variables to one nested hash of pure ruby values.  UseCase methods should return this object as the sole results object to be rendered as HTML or JSON to requester.</dd>
                          <dd>&nbsp;</dd>
                        <dt>Wrap APIs in helpers</dt>
                          <dd>Create a few View helpers to aid in the HTML rendering or controller interface; to minimize Rails View API changes and the number of partials needed.</dd>
                          <dd>&nbsp;</dd>
                        <dt>Use seperate Directory</dt>
                        <dd>Establish a namespaced directory structure to contain your application components; possibly <code>app/strategy</code></dd>
                      </dl>
  
                      <p>Having your business or application logic in PORO class containers, improves your understanding of its components and your ability to add or enhance features.  Depending on how successful
                        you were in separating your application code from Rails you may be able to run your full test suite by injecting memory-based dependencies for testing rather than Rails based dependencies; and never even startup Rails!</p>
                      <p>However, the <strong>SknStrategy</strong> is not another Web Framework! It is a thought provoking alternative to the Rails Way. An alternative that still
                        builds applications using the full capabilities of Rails, while keeping your business logic components separate from Rails; and enables you to easily add or change features.</p>
                      <p class="lead">SknServices serves as a model for how Ruby applications can be engineered to use the Web without sacrificing longevity or major reworks.</p>
                  </div>
              </div>
              <p>Rails is a Great Web Framework.  Your application can derive great benefit from Rails when engineered (Designed) to co-exist with Rails.</p>
  