Rotterdam.rb Domain Driven Design

Iain Hecker

• Ruby developer at Finalist IT Group

• 4 years of Ruby experience

• Contributed to Rails core / i18n

• 9 gems released

• http://iain.nl

• http://github.com/iain

• @iain_nl

symptoms

• maintaining code is annoying

• adding features is a pain

• development speed is low

• system is unstable, but you don't exactly know why

• inconsistency and side effects fuck everything up

• fear of upgrading

• "I'm not touching that code!"

accidental complexity
vs.
essential complexity

"I need to do ..... because the code needs ....."
vs.
"I need to do ..... because the business needs ....."

lower accidental complexity

• use great frameworks (like Rails)

• test all the fucking time

• refactor all the fucking time

• use programming patterns (like MVC)

• pair-programming

"Tackling Complexity in the Heart of Software"

organizing essential complexity

actions to organize complexity

• use the right language

• ﬁnding the core domain

• set the proper boundaries

• ﬁnd the right models

ubiquitous language

technical terms domain model terms business terms

refactor when you got the name wrong

AgreementReference

AgreementSubscription
AgreementType

Agreement

AgreementReference RecentView UserSession

AgreementType

User

Agreement


AgreementType
SearchSubscription
User

Agreement
Search


AgreementType
SearchSubscription
User

Agreement
Search

Party

Department

Person
Group

Member


AgreementType
SearchSubscription
User

Agreement
Search

ProgressNote Party

Department
Mutation

Person
Group

Member


AgreementType
SearchSubscription
User

Agreement
Search

ProgressNote Party

Department
Mutation

Person
Meeting Group

Notiﬁcation
Member

bounded contexts

• boundaries lower complexity

• different contexts can interfere

• leaking between boundaries is called coupling

• side effects are bound to one context

domain types

• core domains

• support domains

• generic support domains

As an council member (gemeenteraadslid)
I can see which agreements have been made
So I can supervise the execution of my policy

As a civil servant (ambtenaar)
I can see which agreements have been made
So I know what to work on

adding real value

• ﬁnd what is important for your users

• invest time and effort in designing those core domains

• slack your efforts in support domains

• use existing products for generic support domains (like authentication)

models

• describe a version of reality to solve a certain problem

• do not represent technical terms like 'database tables'

• have a meaning in the business domain

AgreementReference

AgreementType
User

Agreement
Search

Mutation

Party

Meeting

Reference
User

Subscription
Type
Search
Agreement

Involvement
Responsible

Charger

Charged

Party
Mutation Meeting

Mexico - United States barrier

Reference
user

Subscription
Type
search
Agreement

Involvement
Responsible

Charger

Charged

party
mutation meeting

Reference
user

Subscription
Type
search
Agreement

Involvement
Responsible

Charger

Charged

one normalized table
party
mutation meeting

module Agreement
  class Involvement
    has_one :charged,     :class_name => "Party::Group"
    has_one :charger,     :class_name => "Party::Group"
    has_one :responsible, :class_name => "Party::Group"
  end
end

module Party
  class Group < ActiveRecord::Base
  end
end

Reference
user

Subscription
Type
search
Agreement

Involvement
Responsible

Charger

Charged
party

mutation meeting

not just 3 boundary violations

module Agreement

  class Involvement

    def charger_busy?
      charger.tasks.count > 4
    end

    def charged_busy?
      charger.tasks.count > 0
    end

  end

end

module Party


    def busy_charger?
      tasks.count > 4
    end

    def busy_charged?
      tasks.count > 0
    end

  end

end

module Party


    def busy?(charger = true)
      tasks.count > (charger ? 4 : 0)
    end

  end

end

one simple breach of the boundary can cause a lot of pain

end

module Agreement
  class Involvement
    has_one :charged
    has_one :charger
    has_one :responsible
  end
  class Charged < Group
  end
  class Charger < Group
  end
  class Responsible < Group
  end
end

}
end

module Agreement
  class Involvement
    has_one :charged
    has_one :charger

domain logic
  end
  end
  end
  end
end

} implementation detail

}
end

module Agreement
  class Involvement
    has_one :charged
    has_one :charger

domain logic
  end
  end
  end
  end
end

  delegate :count, :to => :tasks, :preﬁx => true
end

module Agreement

    def busy?
      tasks_count > 0
    end
  end

    def busy?
      tasks_count > 4
    end
  end

end

there are other beneﬁts too!

some (unrelated) problems of bleeding boundaries

class Post < ActiveRecord::Base
  scope :published, where(:published => true)
end

class PostsController < ApplicationController
  respond_to :html
  def index
    respond_with(@posts = Post.published)
  end
  def show
    respond_with(@post = Post.published.ﬁnd(params[:id]))
  end
end

  scope :visible, where(:visible => true)
end

  respond_to :html
  def index
    respond_with(@posts = Post.published.visible.all)
  end
  def show
    respond_with(@post = Post.published.visible.ﬁnd(params[:id])
  end
end

  scope :visible, where(:visible => true)
  scope :for_frontend, published.visible
end

  respond_to :html
  def index
    respond_with(@posts = Post.for_frontend.all)
  end
  def show
    respond_with(@post = Post.for_frontend.ﬁnd(params[:id])
  end
end

but that introduces a lot of complexity for admins

"the local representative pattern"

term coined right now by me

# app/models/frontend/post.rb
module Frontend
  class Post < ::Post
    default_scope published.visible
  end
end

# app/controllers/frontend/posts_controller.rb
module Frontend
  class PostsController
    respond_to :html
    def index
      respond_with(@posts = Post.all)
    end
    def show
      respond_with(@post = Post.ﬁnd(params[:id]))
    end
  end
end

module PersonalModel
  extend ActiveSupport::Concern

  included do
    attr_accessor :current_user
module Public
    before_update :check_current_user
  class Comment < ::Comment
    before_destroy :check_current_user
    include PersonalModel
  end
    attr_accessible :body
  end
  def owned_record?
end
    current_user == user
  end

  def check_current_user
    raise UnauthorizedUserError.new(self) unless owned_record?
  end

end

works great for

• (default) scopes

• validations

• attr_protected / attr_accessible

• associations

• any other piece of code

problems

• introduces problems with identity

• getting the right objects

• Rails conventions

class Comment < ActiveRecord::Base
end

module Frontend
class Comment < ::Comment
end
end

Comment.ﬁrst != Frontend::Comment.ﬁrst

class Public::CommentsController < ApplicationController
  respond_to :html
  def new
    respond_with(@comment = Comment.new)
  end
end

class Public::CommentsController < ApplicationController
  respond_to :html
  def new
  end
end

module Public
  class CommentsController < ApplicationController
    respond_to :html
    def new
    end
  end
end

= form_for Comment.new do |f|
= f.text_ﬁeld :body

<form action="/comments" method="post">
<input type="text" name="comment[body]" id="comment_body" />
</form>

= form_for Comment.new do |f|

<form action="/comments" method="post">
  <input type="text" name="comment[body]" id="comment_body" />
</form>

= form_for @comment do |f|

<form action="/public/comments" method="post">
  <input type="text" name="public_comment[body]" id="public_comment_body" />
</form>

keep accidental complexity to a minimum

essential complexity needs to be clear and organized

prioritize on what you design perfectly

Rotterdam.rb Domain Driven Design

Recomendados

Recomendados

Más contenido relacionado

Último

Último (20)

Destacado

Destacado (20)

Rotterdam.rb Domain Driven Design

Notas del editor