nicholasjhenry

class NewsItem
  
  scope :news_items, where(flag_news: true).order("publish_date DESC")
  scope :press_releases, lambda { where(flag_news: false).order("publish_date DESC") }

  scope :news_items_homepage, where(flag_news: true, featured: true).order("publish_date DESC")
  scope :press_releases_homepage, lambda { where(flag_news: false, featured: true).order("publish_date DESC") }
end

nicholasjhenry

# Data: Simple classes that encapsulate properties and associations.
# The only valid operations for a data object, is modify properties
# and associations.
class Site

  attr_reader :content_items

  def initialize
    @content = []
  end

nicholasjhenry

# Example:
#
#   submit_order = SubmitOrder.new(current_user, order)
#   submit_order.call
#
# Uses RubyEvents: https://github.com/nathankleyn/ruby_events

# app/use_cases/submit_order.rb

class SubmitOrder

nicholasjhenry

# As seen from the example below, you could imagine a Rails application 
# "depending" on this application logic. Controllers would act as the 'main' 
# instantiating collaborators to inject into the service (aka use case).

# "Note that the collaborators of the birthdayService objects are injected in 
# it. Ideally domain code should never use the new operator. The new operator is
# called from outside the domain code, to set up an aggregate of objects that 
# collaborate together." - http://matteo.vaccari.name/blog/archives/154

class BirthdayService

nicholasjhenry

module Refinery
  module CustomFeature
    class Engine < Rails::Engine

      initializer "core.load_app_instance_data" do |app|
        app.class.configure do
          # Add migrations to the host application's path
          config.paths['db/migrate'] += Refinery::Templates::Engine.paths['db/migrate'].existent
        end
      end

nicholasjhenry

Design in the Small

• Don't design a Model to be coupled to an API
• Create a Service that talks to both your Model and the API

Service Wrapper Record

• You have services, stateless objects that talk to the application
• You have records, objects that talk to the database
• And you have Wrappers, a thin class for a narrow interface to an API

nicholasjhenry

module ApplicationHelper
  def render_dat(&block)                                                                                                                
    content_tag(:div, class: 'nav') do                 
      block.call                                                   
      concat(@context.render('menu', foo: 'bar'))       
    end                                                            
  end
end                                                              

nicholasjhenry

class QueryTrace < ActiveSupport::LogSubscriber
  def sql(event)
    return unless logger.debug?

    debug caller.
      select {|stack| stack =~ /\/app\//}.
        map {|stack| stack.gsub(/^.*app\//, '')}.
          join("\n")
  end

nicholasjhenry

class GetItemService < Struct.new( :id, :responder )
  def get
    item = Item.find( id )
    item ? responder.success( item ) : responder.failure( item )
  end
end

class GetItemResponder < SimpleDelegator
  def success( item )
    @item = item

nicholasjhenry

# Source: https://gist.github.com/4172391#gistcomment-610165

class Order
  def complete_purchase(purchase)
    purchase.complete(credit_card, amount)
  end

  def purchase_completed(transaction_reference)
    update_attibutes(:transaction_reference => transaction_reference)
  end