Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Toon Ketels

December 05, 2013
Tweet

More Decks by Toon Ketels

Other Decks in Programming

Transcript

  1. How to build Single-Page Apps
    TOOLS

    &

    DOMAIN DRIVEN DESIGN

    View Slide

  2. Toon Ketels
    Freelance JavaScript Developer
    @toonketels

    toon.io

    View Slide

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

    View Slide

  4. zwerm developer wanted

    View Slide

  5. zwerm developer wanted

    View Slide

  6. zwerm developer wanted

    View Slide

  7. museus developer wanted

    View Slide

  8. How to build Single Page JavaScript apps?

    View Slide

  9. WHAT

    View Slide

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

    View Slide

  11. complexity

    View Slide

  12. What I think is valuable
    5 THINGS

    View Slide

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

    View Slide

  14. View Slide

  15. View Slide

  16. Faster development because of reliable cross-browser api

    View Slide

  17. Whatever we build, it runs cross-browser

    View Slide

  18. cross-browser
    spaghetti code

    View Slide

  19. Complexity of understanding which code does what
    MV*
    Use a framework to structure your code

    View Slide

  20. View Slide

  21. View Slide

  22. View Slide

  23. View Slide

  24. View Slide

  25. View Slide

  26. Every framework has its own notions,
    tools to bring structure

    View Slide

  27. Separation of concerns

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  31. Use a module system
    3
    Complexity by loosing oversight

    View Slide

  32. View Slide

  33. AMD module

    View Slide

  34. application files

    View Slide

  35. index.html

    View Slide

  36. config.js

    View Slide

  37. main.js

    View Slide

  38. Sane amounts of code

    Better file structure

    Explicit about code dependencies

    Easier debugging

    (code re-use)

    View Slide

  39. Whatever we build,
    it’s easier to understand, modify, maintain
    and re-use

    View Slide

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

    View Slide

  41. Complexity by ever changing code
    4
    Write tests

    View Slide

  42. View Slide

  43. unit test

    View Slide

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

    View Slide

  45. Use a task runner
    5
    Complexity of workflows

    View Slide

  46. View Slide

  47. Gruntfile.js

    View Slide

  48. We can hook into it anything we want

    View Slide

  49. Fast

    Repeatable/less errors

    Understood by everyone in the team

    View Slide

  50. Whatever we build, we build it automatically

    View Slide

  51. OUR TOOLS

    View Slide

  52. Cross browser utility libs

    Code structure frameworks

    Module system

    Testing

    Task runner

    View Slide

  53. All nice tools to help us to build whatever we
    want more reliable, faster and easier

    View Slide

  54. None will help us answer the most important
    question...

    View Slide

  55. WHAT

    to build
    ?

    View Slide

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

    View Slide

  57. Complexity by not understanding

    what the application should do
    Domain Driven Design

    View Slide

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

    View Slide

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

    View Slide

  60. Your ability to reason about your program is critical
    to changing it without fear
    Rich Hickey

    View Slide

  61. We need to understand what to build
    We need to understand once it’s build

    View Slide

  62. Domain Driven Design

    View Slide

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

    View Slide

  64. View Slide

  65. Application domain
    Understand it by building a model of it
    Convert model into code

    View Slide

  66. Application domain

    View Slide

  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

    View Slide

  68. What the application is about

    View Slide

  69. Reduce the entire application to its essence

    View Slide

  70. Illustrator
    Banking application
    Gmail

    View Slide

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

    View Slide

  72. Model

    View Slide

  73. Anything used in any way to represent something else
    Simplified version of reality
    We only keep the traits we’re interested in

    View Slide

  74. View Slide

  75. View Slide

  76. View Slide

  77. What resolution?
    Everything should be made as simple as possible, but no simpler.
    Albert Einstein

    View Slide

  78. Challenge 1
    Creating a conceptual modal of the application domain

    View Slide

  79. Talk to domain experts

    View Slide

  80. Key Concepts
    Ubiquitous Language

    View Slide

  81. Make everyone involved understand the conceptual model

    View Slide

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

    View Slide

  83. Iterate
    Keep it up to date

    View Slide

  84. Challenge 2
    Translating the conceptual modal into working code

    View Slide

  85. Application screens
    Application model
    vs

    View Slide

  86. Application model is a reduction of the application

    View Slide

  87. Dividing the application into layers

    View Slide

  88. Application layers

    View Slide

  89. a layer has a common goal and it has rules how to interact with
    other layers

    View Slide

  90. User Interface
    Application Layer
    Domain Layer
    Infrastructure Layer

    View Slide

  91. Responsible for presenting information to the user and interpreting user commands
    Application Layer
    Domain Layer
    Infrastructure Layer

    View Slide

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

    View Slide

  93. User Interface
    Application Layer
    The heart of the business software. Contains the state of business objects
    Infrastructure Layer

    View Slide

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

    View Slide

  95. application structure

    View Slide

  96. Start building the domain layer

    View Slide

  97. Entities
    Value objects
    vs

    View Slide

  98. Repository

    View Slide

  99. Factories

    View Slide

  100. domain layer

    View Slide

  101. Application layer

    View Slide

  102. Whatever makes the UI layer possible

    View Slide

  103. application layer

    View Slide

  104. UI layer

    View Slide

  105. UI layer

    View Slide

  106. UI layer

    View Slide

  107. Infrastructure layer

    View Slide

  108. Persistence
    Communication with backend

    View Slide

  109. Realtime communication
    Offline first

    View Slide

  110. THAT’S IT

    View Slide

  111. Domain Driven Design

    Cross browser utility libs

    Code structure frameworks

    Module system

    Testing

    Task runner

    View Slide

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

    View Slide