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

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
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
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
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
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
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
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
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#!