Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
How to build Single-Page Apps TOOLS & DOMAIN DRIVEN DESIGN
Slide 2
Slide 2 text
Toon Ketels Freelance JavaScript Developer @toonketels toon.io
Slide 3
Slide 3 text
Developer wanted http://www.vacature.com/jobs/iminds/living-lab-software-prototype-developer#! Living Labs | Prototyping
Slide 4
Slide 4 text
zwerm developer wanted
Slide 5
Slide 5 text
zwerm developer wanted
Slide 6
Slide 6 text
zwerm developer wanted
Slide 7
Slide 7 text
museus developer wanted
Slide 8
Slide 8 text
How to build Single Page JavaScript apps?
Slide 9
Slide 9 text
WHAT
Slide 10
Slide 10 text
JavaScript Rendered Client-side Data and Business Logic REST, RPC, Realtime...
Slide 11
Slide 11 text
complexity
Slide 12
Slide 12 text
What I think is valuable 5 THINGS
Slide 13
Slide 13 text
Use cross-browser utility libs Complexity of different run-time environments
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
Faster development because of reliable cross-browser api
Slide 17
Slide 17 text
Whatever we build, it runs cross-browser
Slide 18
Slide 18 text
cross-browser spaghetti code
Slide 19
Slide 19 text
Complexity of understanding which code does what MV* Use a framework to structure your code
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
No content
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
Every framework has its own notions, tools to bring structure
Slide 27
Slide 27 text
Separation of concerns
Slide 28
Slide 28 text
Each part of the code has its own clear goal
Slide 29
Slide 29 text
Whatever we build, it’s easier to understand, modify, maintain
Slide 30
Slide 30 text
if we can find what we’re looking for
Slide 31
Slide 31 text
Use a module system 3 Complexity by loosing oversight
Slide 32
Slide 32 text
No content
Slide 33
Slide 33 text
AMD module
Slide 34
Slide 34 text
application files
Slide 35
Slide 35 text
index.html
Slide 36
Slide 36 text
config.js
Slide 37
Slide 37 text
main.js
Slide 38
Slide 38 text
Sane amounts of code Better file structure Explicit about code dependencies Easier debugging (code re-use)
Slide 39
Slide 39 text
Whatever we build, it’s easier to understand, modify, maintain and re-use
Slide 40
Slide 40 text
So we make changes and deploy our new modular code
Slide 41
Slide 41 text
Complexity by ever changing code 4 Write tests
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
unit test
Slide 44
Slide 44 text
Whatever change we’re making, we know it does not break things
Slide 45
Slide 45 text
Use a task runner 5 Complexity of workflows
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
Gruntfile.js
Slide 48
Slide 48 text
We can hook into it anything we want
Slide 49
Slide 49 text
Fast Repeatable/less errors Understood by everyone in the team
Slide 50
Slide 50 text
Whatever we build, we build it automatically
Slide 51
Slide 51 text
OUR TOOLS
Slide 52
Slide 52 text
Cross browser utility libs Code structure frameworks Module system Testing Task runner
Slide 53
Slide 53 text
All nice tools to help us to build whatever we want more reliable, faster and easier
Slide 54
Slide 54 text
None will help us answer the most important question...
Slide 55
Slide 55 text
WHAT to build ?
Slide 56
Slide 56 text
No library, code, fancy tool will help us with that
Slide 57
Slide 57 text
Complexity by not understanding what the application should do Domain Driven Design
Slide 58
Slide 58 text
Everything seems complex as you don’t understand it
Slide 59
Slide 59 text
We can only hope to make reliable those things we can understand Rich Hickey
Slide 60
Slide 60 text
Your ability to reason about your program is critical to changing it without fear Rich Hickey
Slide 61
Slide 61 text
We need to understand what to build We need to understand once it’s build
Slide 62
Slide 62 text
Domain Driven Design
Slide 63
Slide 63 text
Domain Driven Design an approach to develop complex/evolving software applications
Slide 64
Slide 64 text
No content
Slide 65
Slide 65 text
Application domain Understand it by building a model of it Convert model into code
Slide 66
Slide 66 text
Application domain
Slide 67
Slide 67 text
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
Slide 68
Slide 68 text
What the application is about
Slide 69
Slide 69 text
Reduce the entire application to its essence
Slide 70
Slide 70 text
Illustrator Banking application Gmail
Slide 71
Slide 71 text
Business Model Editor Visualizing business models and investigate profitability characteristics
Slide 72
Slide 72 text
Model
Slide 73
Slide 73 text
Anything used in any way to represent something else Simplified version of reality We only keep the traits we’re interested in
Slide 74
Slide 74 text
No content
Slide 75
Slide 75 text
No content
Slide 76
Slide 76 text
No content
Slide 77
Slide 77 text
What resolution? Everything should be made as simple as possible, but no simpler. Albert Einstein
Slide 78
Slide 78 text
Challenge 1 Creating a conceptual modal of the application domain
Slide 79
Slide 79 text
Talk to domain experts
Slide 80
Slide 80 text
Key Concepts Ubiquitous Language
Slide 81
Slide 81 text
Make everyone involved understand the conceptual model
Slide 82
Slide 82 text
Documentation Notes (UML) diagrams Mindmaps Sketches Code Specs (tests)
Slide 83
Slide 83 text
Iterate Keep it up to date
Slide 84
Slide 84 text
Challenge 2 Translating the conceptual modal into working code
Slide 85
Slide 85 text
Application screens Application model vs
Slide 86
Slide 86 text
Application model is a reduction of the application
Slide 87
Slide 87 text
Dividing the application into layers
Slide 88
Slide 88 text
Application layers
Slide 89
Slide 89 text
a layer has a common goal and it has rules how to interact with other layers
Slide 90
Slide 90 text
User Interface Application Layer Domain Layer Infrastructure Layer
Slide 91
Slide 91 text
Responsible for presenting information to the user and interpreting user commands Application Layer Domain Layer Infrastructure Layer
Slide 92
Slide 92 text
User Interface Coordinates the application activity, can hold state task progress Domain Layer Infrastructure Layer
Slide 93
Slide 93 text
User Interface Application Layer The heart of the business software. Contains the state of business objects Infrastructure Layer
Slide 94
Slide 94 text
User Interface Application Layer Domain Layer Persistence of the business objects
Slide 95
Slide 95 text
application structure
Slide 96
Slide 96 text
Start building the domain layer
Slide 97
Slide 97 text
Entities Value objects vs
Slide 98
Slide 98 text
Repository
Slide 99
Slide 99 text
Factories
Slide 100
Slide 100 text
domain layer
Slide 101
Slide 101 text
Application layer
Slide 102
Slide 102 text
Whatever makes the UI layer possible
Slide 103
Slide 103 text
application layer
Slide 104
Slide 104 text
UI layer
Slide 105
Slide 105 text
UI layer
Slide 106
Slide 106 text
UI layer
Slide 107
Slide 107 text
Infrastructure layer
Slide 108
Slide 108 text
Persistence Communication with backend
Slide 109
Slide 109 text
Realtime communication Offline first
Slide 110
Slide 110 text
THAT’S IT
Slide 111
Slide 111 text
Domain Driven Design Cross browser utility libs Code structure frameworks Module system Testing Task runner
Slide 112
Slide 112 text
THANKS Freelance JavaScript Developer @toonketels http://www.vacature.com/jobs/iminds/living-lab-software-prototype-developer#!