Created by Angelo Maron

Transkript

1 Domain Driven Design in Ruby on Rails Created by Angelo Maron

2 Wer bin ich? Angelo Maron Sofware-Entwickler seit ca. 7 Jahren (Ruby on Rails) bei AKRA seit 2,5 Jahren Xing:

3 Aga 1. MVC & Rails 2. Domain Driven Design 3. Domain Driven Design in Rails 4. Zusammenfassung

4 MVC (Model View Controller) Wikipedia: Der englischsprachige Begriff "model view controller" (MVC) ist ein Muster zur Strukturierung von Software-Entwicklung in die drei Einheiten Datenmodell (engl. model), Präsentation (engl. view) und Programmsteuerung (engl. controller).

5 Ruby on Rails Ruby on Rails ist ein in der Programmiersprache Ruby geschriebenes und quelloffenes Web Application Framework. wird dieses Jahr 10 Jahre alt. basiert auf dem MVC-Pattern Prinzipien: Don't repeat yourself (DRY) Convention over Configuration

6 !Convention!

7 MVC in Ruby on Rails M odel: V iew: ActiveRecord ActionView C ontroller: ActionController

8 Fat Model, Skinny Con- troller (1) "Im Zusammenspiel von Controller und Model, versuche im Controller nur das Objekt zu instanzieren und einen Methodenaufruf durchzuführen. Der Rest wird im Model definiert."

9 Fat Model, Skinny Con- troller (2) def = Post.all.where('published_at <=?', = Post.all.where('published_at IS NULL or published_at >?', Time.now) def = = Post.all_unpublished

10 Problematik Mit zunehmen Anforderungen werden können die folgen Problematiken auftreten: Die Model-Dateien werden immer größer (500+ Zeilen) Die Actions der Controller werden immer größer (30+ Zeilen) Dies führt zur Verschlechterung der Testbarkeit, Wartbarkeit und Verständnis des Codes. Daher habe ich versucht nach den folgen Regeln zu arbeiten. (nach Sandy Matz) --> Domain Driven Design Eine Klasse hat maximal 100 Zeilen. Eine Methode hat maximal 5 Zeilen.

11 Domain Driven Design Domain-Driven Design (DDD) ist eine Herangehensweise an die Modellierung komplexer objektorientierter Software. Die Modellierung der Software wird dabei maßgeblich von den umzusetzen Fachlichkeiten der Anwungsdomäne beeinflusst.

12 Warum DDD? 1. Fachliche Begrifflichkeiten und Codestruktur angleichen. 2. kleinere Dateien (bessere Wartbarkeit) 3. höhere Codeunabhängigkeit (bessere Wartbarkeit) 4. Bessere Testbarkeit (durch kleinere Klassen)

13 Domain-Driven Design in Rails Rails Helpers Concerns Service Objects Presenter Objects Strukturierte Namensräume Decorator Pattern

14 Rails Helpers Interne Struktur von Rails um Funktionen für views zur Verfügung zu stellen. Funktionen um komplexen Code aus der View zu halten. Sich wiederhole Funktionen wieder zu verwen. Persönlich: (erinnert mich an funktionale Programmierung)

15 Beispiel Rails Helper (1) <div> <%- %> <%= %> <%- else %> <%= image_tag(asset_path('default_profile.png')) %> <%- %> </div>

16 Beispiel Rails Helper (2) module UserHelper def user_picture_path(user) if user.image.present? user.image.path else asset_path('default_profile.png') <div> <%= %> </div>

17 Domain-Driven Design in Rails Rails Helpers Concerns Service Objects Presenter Objects Strukturierte Namensräume Decorator Pattern

18 Rails Concerns Rails Concerns ist eine Möglichkeit Code in Module auszulagern, die man über ein include in ein beliebiges Model inkludieren kann. Dieses hat folge Anwungsmöglichkeiten: 1. Aufteilen des Codes eines Models in mehrere Dateien 2. Auslagerung von Mechanismen/Pattern zur Wiederverwung Rails bietet hier ein hauseigenes Konzept: ActiveSupport::Concern

19 Beispiel Rails Concerns (1) class Article < ActiveRecord::Base belongs_to :create_user, class_name: 'User' belongs_to :update_user, class_name: 'User' class Job < ActiveRecord::Base belongs_to :create_user, class_name: 'User' belongs_to :update_user, class_name: 'User'

20 Beispiel Rails Concerns (2) module Trackable ext ActiveSupport::Concern included do belongs_to :create_user, class_name: 'User' belongs_to :update_user, class_name: 'User' class Article < ActiveRecord::Base include Trackable class Job < ActiveRecord::Base include Trackable

21 Domain-Driven Design in Rails Rails Helpers Concerns Service Objects Presenter Objects Strukturierte Namensräume Decorator Pattern

22 Service Objects Verlagerung bestimmter Funktionen eines Anwungsfall in ein eigenes Objekt, dass genau diese Funktionen zur Verfügung stellt. zum Beispiel: SearchService (Suchkomponente) InvoiceService (Rechnungserstellung) RegistrationService (RegistrierungsValidierung)

23 Beispiel Service Object (1) class Article < ActiveRecord::Base def search(term, options = {}) # execute search def admin_search(term, options = {}) # execute search from admin perspective def Job < ActiveRecord::Base def search(term, options = {}) # execute search def admin_search(term, options = {}) # execute search from admin perspective

24 Beispiel Service Object (2) class SearchService def self.article_search(term, options = {}) # execute search here def self.job_search(term, options = {}) # execute search here class AdminSearchService def self.article_search(term, options = {}) # execute search here def self.job_search(term, options = {}) # execute search here

25 Domain-Driven Design in Rails Rails Helpers Concerns Service Objects Presenter Objects Strukturierte Namensräume Decorator Pattern

26 Presenter Objects Oft haben Get-Operationen komplexe Analyse von Parametern, um die genau angeforderten Objekte anzuzeigen. Hier gibt es eine gute Möglichkeit, diese in eigene Objekte auszulagern.

27 Beispiel Presenter Object (1) class JobController < ApplicationController::Base def = Job.active.preload(:items) if if params[:order] order_string = "#{params[:order]} #{params[:dir].presence = 1).per(params[:per].presence 10)

28 Beispiel Presenter Object (2) class JobController < ApplicationController::Base def = JobPresenter.get_all(params) class JobPresenter def self.get_all(params) self.new(params).get_all def = params def get_all jobs = Job.active.preload(:items) jobs = jobs.by_state(@params[:state])

29 Domain-Driven Design in Rails Rails Helpers Concerns Service Objects Presenter Objects Strukturierte Namensräume Decorator Pattern

30 Strukturierte Namen- sräume Strukturierung aller Objekte (Models, Services, Presenters, Decorators, Controllers usw.) in Domain-basierte Namespaces. Dies hat folge Vorteile: Code-Unabhängigkeit kleinere Dateien bessere Abbildung der Businessdomäne im Code.

31 Beispiel Namensräume (1) class Job < ActiveRecord::Base def self.all_for_admins #execute query here def self.all_for_moderators # execute query here def self.all_for_visitors #execute query here

32 Beispiel Namensräume (2) module Admins class Job def self.all #execute query here module Moderators class Job def self.all #execute query here module Visitors class Job def self.all #execute query here

33 Domain-Driven Design in Rails Rails Helpers Concerns Service Objects Presenter Objects Strukturierte Namensräume Decorator Pattern

34 Decorators in Rails (1)

35 Decorators in Rails (2)

36 Beispiel Decorator (1) class UserController < ApplicationController::Base def = User.find(params[:id]) <div> <p>erstellt am: <p>name: %></p> <%- %> <%= image_tag(@user.image.path) %> <%- else %> <%= image_tag(asset_path('default_profile.png')) %> <%- %> </div>

37 Beispiel Decorator (2) class UserDecorator < SimpleDelegator def def name def image_path # return image.path or default class UserController < ApplicationController::Base def = UserDecorator.new(User.find(params[:id])) <div> <p>erstellt am:

38 Und was nun?

39 Die alles entscheidene Frage Welches Pattern benutzt man wann? Ab wann benutzen wir überhaupt diese Pattern?

40 Neuprogrammierung Abwägung der Komplexität gegen den entstehen Aufwand. Wichtig: Komplexe Business-Logik lässt sich nur durch komplexen Code abbilden.

41 Refactoring Oft ist schon ein gewisser Fortschritt da, bevor man merkt, dass die Komplexität der Domaine sich direkt im Code wiederspiegelt. Nicht gleich alles komplett refactorn, sondern Step by Step.

42 Beispiel:

43

44

45