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

Building better client-side JavaScript applicat...

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. Sane amounts of code Better file structure Explicit about code

    dependencies Easier debugging (code re-use)
  2. All nice tools to help us to build whatever we

    want more reliable, faster and easier
  3. Your ability to reason about your program is critical to

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

    understand once it’s build
  5. 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
  6. Anything used in any way to represent something else Simplified

    version of reality We only keep the traits we’re interested in
  7. a layer has a common goal and it has rules

    how to interact with other layers
  8. Responsible for presenting information to the user and interpreting user

    commands Application Layer Domain Layer Infrastructure Layer
  9. User Interface Application Layer The heart of the business software.

    Contains the state of business objects Infrastructure Layer