Pro Yearly is on sale from $80 to $50! »

Building better client-side JavaScript applications - Tools & Domain Driven Design

2aacf6307821d3301fac1f47a214307b?s=47 Toon Ketels
December 05, 2013

Building better client-side JavaScript applications - Tools & Domain Driven Design

We’re migrating more and more logic from the server to the client. This makes for a better user experience but at the same time makes our client side applications more complex, harder to debug and to maintain.

We see an explosion of framework and tools to combat this complexity. Building application with Grunt, unit testing with Chai and Mocha, writing integration tests with Casper, dividing applications in modules with Require and structuring applications with Backbone/Marionette, Angular or Ember.

Though all this tech makes certain parts easier, it alone does not help to keep your application understandable, well structured and correctly designed for the problems it needs to solve.

Enter Domain Driven Design. It’s an approach to develop complex software applications. On the one hand, it’s a process to transform requirements into an actual product. On the other, it clearly describes how to structure applications and which design patterns and objects to use.

It’s the missing link to properly leverage all the tools our frameworks provide to create complex client-side applications.

This talk provides an overview of tools used to created single page apps, introduces Domain Driven Design and how to apply it building complex client-side JavaScript applications.

Presented at Fronteers Meetup - Hasselt, Belgium

2aacf6307821d3301fac1f47a214307b?s=128

Toon Ketels

December 05, 2013
Tweet

Transcript

  1. How to build Single-Page Apps TOOLS & DOMAIN DRIVEN DESIGN

  2. Toon Ketels Freelance JavaScript Developer @toonketels toon.io

  3. Developer wanted http://www.vacature.com/jobs/iminds/living-lab-software-prototype-developer#! Living Labs | Prototyping

  4. zwerm developer wanted

  5. zwerm developer wanted

  6. zwerm developer wanted

  7. museus developer wanted

  8. How to build Single Page JavaScript apps?

  9. WHAT

  10. JavaScript Rendered Client-side Data and Business Logic REST, RPC, Realtime...

  11. complexity

  12. What I think is valuable 5 THINGS

  13. Use cross-browser utility libs Complexity of different run-time environments

  14. None
  15. None
  16. Faster development because of reliable cross-browser api

  17. Whatever we build, it runs cross-browser

  18. cross-browser spaghetti code

  19. Complexity of understanding which code does what MV* Use a

    framework to structure your code
  20. None
  21. None
  22. None
  23. None
  24. None
  25. None
  26. Every framework has its own notions, tools to bring structure

  27. Separation of concerns

  28. Each part of the code has its own clear goal

  29. Whatever we build, it’s easier to understand, modify, maintain

  30. if we can find what we’re looking for

  31. Use a module system 3 Complexity by loosing oversight

  32. None
  33. AMD module

  34. application files

  35. index.html

  36. config.js

  37. main.js

  38. Sane amounts of code Better file structure Explicit about code

    dependencies Easier debugging (code re-use)
  39. Whatever we build, it’s easier to understand, modify, maintain and

    re-use
  40. So we make changes and deploy our new modular code

  41. Complexity by ever changing code 4 Write tests

  42. None
  43. unit test

  44. Whatever change we’re making, we know it does not break

    things
  45. Use a task runner 5 Complexity of workflows

  46. None
  47. Gruntfile.js

  48. We can hook into it anything we want

  49. Fast Repeatable/less errors Understood by everyone in the team

  50. Whatever we build, we build it automatically

  51. OUR TOOLS

  52. Cross browser utility libs Code structure frameworks Module system Testing

    Task runner
  53. All nice tools to help us to build whatever we

    want more reliable, faster and easier
  54. None will help us answer the most important question...

  55. WHAT to build ?

  56. No library, code, fancy tool will help us with that

  57. Complexity by not understanding
 what the application should do Domain

    Driven Design
  58. Everything seems complex as you don’t understand it

  59. We can only hope to make reliable those things we

    can understand Rich Hickey
  60. Your ability to reason about your program is critical to

    changing it without fear Rich Hickey
  61. We need to understand what to build We need to

    understand once it’s build
  62. Domain Driven Design

  63. Domain Driven Design an approach to develop complex/evolving software applications

  64. None
  65. Application domain Understand it by building a model of it

    Convert model into code
  66. Application domain

  67. A sphere of knowledge (ontology), influence, or activity. The subject

    area to which the user applies a program is the domain of the software. Wikipedia
  68. What the application is about

  69. Reduce the entire application to its essence

  70. Illustrator Banking application Gmail

  71. Business Model Editor Visualizing business models and investigate profitability characteristics

  72. Model

  73. Anything used in any way to represent something else Simplified

    version of reality We only keep the traits we’re interested in
  74. None
  75. None
  76. None
  77. What resolution? Everything should be made as simple as possible,

    but no simpler. Albert Einstein
  78. Challenge 1 Creating a conceptual modal of the application domain

  79. Talk to domain experts

  80. Key Concepts Ubiquitous Language

  81. Make everyone involved understand the conceptual model

  82. Documentation Notes (UML) diagrams Mindmaps Sketches Code Specs (tests)

  83. Iterate Keep it up to date

  84. Challenge 2 Translating the conceptual modal into working code

  85. Application screens Application model vs

  86. Application model is a reduction of the application

  87. Dividing the application into layers

  88. Application layers

  89. a layer has a common goal and it has rules

    how to interact with other layers
  90. User Interface Application Layer Domain Layer Infrastructure Layer

  91. Responsible for presenting information to the user and interpreting user

    commands Application Layer Domain Layer Infrastructure Layer
  92. User Interface Coordinates the application activity, can hold state task

    progress Domain Layer Infrastructure Layer
  93. User Interface Application Layer The heart of the business software.

    Contains the state of business objects Infrastructure Layer
  94. User Interface Application Layer Domain Layer Persistence of the business

    objects
  95. application structure

  96. Start building the domain layer

  97. Entities Value objects vs

  98. Repository

  99. Factories

  100. domain layer

  101. Application layer

  102. Whatever makes the UI layer possible

  103. application layer

  104. UI layer

  105. UI layer

  106. UI layer

  107. Infrastructure layer

  108. Persistence Communication with backend

  109. Realtime communication Offline first

  110. THAT’S IT

  111. Domain Driven Design Cross browser utility libs Code structure frameworks

    Module system Testing Task runner
  112. THANKS Freelance JavaScript Developer @toonketels http://www.vacature.com/jobs/iminds/living-lab-software-prototype-developer#!