Domain-Driven JavaScript Development

Domain Driven Design (DDD) is an architectural pattern that focuses on building an accurate model of the business logic of an application. While remaining separate from the other layers of the architecture, this conceptual model is closely tied to the software implementation of that model. The benefits of this approach include flexibility, maintainability, and an easing of communication between the technical and domain experts.

DDD is somewhat established on the server side, but has seen very little use in client-side applications. We will introduce Keel.js: a very light framework on top of Backbone.js, which allows us to easily build domain-driven applications. We will discuss both the benefits and challenges of this approach.

Transcript

1. Domain-­‐Driven  JavaScript   Development   h3p://www.flickr.com/photos/lac-­‐bac/4678565737/  
2. Bob  Holt   Specialist,  InteracFve  Development   Sapient  Global  Markets   VisualizaFon  PracFce               @bobholt   github.com/bobholt  
3. •  Asset  Management   •  Design  Pa3erns   •  ModularizaFon   •  LinFng   •  TesFng   •  Build  Process  
4. h3p://www.flickr.com/photos/sidelong/6433552779/  
5. h3p://en.wikipedia.org/wiki/File:Joy_Oil_gas_staFon_blueprints.jpg  
7. Domain   The  subject  of  the  program     Examples:     •  Airline  booking  program:  People  ge]ng  on  aircra^   •  Stock  Trading  program:  SecuriFes  and  exchanges  
8. Domain-­‐Driven  Design   Manage  complex  so^ware  by  placing  primary   focus  on  the  domain.     •  Principles   •  Techniques   •  PracFces  
9. What  if  my  so^ware  isn’t  complex?   “Put  all  the  business  logic  into  the  user  interface.   […]  Use  the  most  automated  UI  building  and  visual   programming  tools  available.”   -­‐Eric  Evans  
10. h3p://www.flickr.com/photos/sinamigos/7509698756/  
11. Domain-­‐Driven  Design   Manage  complex  so^ware  by  placing  primary   focus  on  the  domain.     •  Principles   •  Techniques   •  PracFces  
12. Domain  Model   •  AbstracFon  of  the  knowledge  in  a  domain   expert’s  head   •  InFmately  linked  with  the  so^ware   implementaFon   •  If  a  domain  model  cannot  be  understood  by   sophisFcated  domain  experts,  then  there  is   something  wrong  with  the  model.  
13. BUILDING  A  DOMAIN-­‐DRIVEN   APPLICATION  
14. h3ps://github.com/archfirst/bullsfirst-­‐jquery-­‐backbone  
16. h3ps://github.com/archfirst/bullsfirst-­‐jquery-­‐backbone  
17. THE  FRAMEWORK   Building  a  Domain-­‐Driven  ApplicaFon  
18. Backbone.js   In  an  ecosystem  where  overarching,  decides-­‐ everything-­‐for-­‐you  frameworks  are   commonplace,  and  many  libraries  require  your   site  to  be  restructured  to  suit  their  look,  feel,   and  default  behavior  —  Backbone  should   conFnue  to  be  a  tool  that  gives  you  the  freedom   to  design  the  full  experience  of  your  web   applicaFon.   -­‐  Jeremy  Ashkenas    
19. Keel   •  Lightweight  framework  around  Backbone.js   •  About  pa3erns  and  pracFces,  not  fancy  code   •  5  Files:  BaseView,  ExcepFonUFl,  Message,   MessageBus,  Router   h3ps://github.com/archfirst/keel  
20. Pa3ern   •  Component   – View     – Template   – ViewModel  
21. h3ps://commons.wikimedia.org/wiki/File:Russian-­‐Matroshka_no_bg.jpg  
22. THE  PROCESS   Building  a  Domain-­‐Driven  ApplicaFon  
23. Discovery   •  Begin  construcFng  the  domain  model   •  Develop  an  UBIQUITOUS  LANGUAGE  
24. Ubiquitous  Language   •  Concept  shared  with  Behavior-­‐Driven   Development   •  Defined  terminology  that  is  shared  between   all  members  of  the  team   •  Used  in  all  code  and  wri3en  and  verbal   communicaFon  
29. Building  the  domain  model  and  ubiquitous   language  is  an  iteraFve  process  
30. Isolate  the  Domain  
31. Express  the  Model  in  So^ware   •  DisFnguish  EnFFes,  Value  Objects,  and   Services   •  Set  Aggregate  Boundaries   •  Implement  Repositories  and  Factories  
32. Set  Aggregate  Boundaries   PosiFons   TransacFons   Orders   Lots   Brokerage  Account  
33. Repositories   •  Global  interface   •  Provides  illusion  of  in-­‐memory  collecFon  of  all   objects   •  Deals  with  the  data  store   •  Caches  as  necessary  
34. Factories   •  Take  on  the  responsibility  of  creaFng  new   objects   •  Tying  to  domain  or  applicaFon  can  be  ungainly   •  However,  Backbone  has  CollecFon.add  and   Model.validate  methods  that  can  take  care  of   this  for  us  
35. h3p://commons.wikimedia.org/wiki/File:Deep_in_thought.jpg  
36. Resources   •  Domain-­‐Driven  Design   – Domain-­‐Driven  Design:  Tackling  Complexity  in  the   Heart  of  So^ware  –  Eric  Evans   – Domain  Driven  Design  Quickly  –  InfoQ   – Domain-­‐Driven  Design  –  Ne3uts+   •  Keel.js   – Keel  –  GitHub   – Bullsfirst  –  GitHub   – Archfirst  Project