Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Most of my client side code ends up as a long script in one file the mostly looks like this:

function someFunction1(){/*...*/}
function someFunction2(){/*...*/}
var globalVariable1;
var globalVariable2;

    //get relevant data from various DOM elements

    //some business logic rules and validation

    //open dialog box

    //more business logic rules and more validation

    //post an ajax request

    //update the DOM    

//many other events

//many jQuery dialogs    

It's a maintenance nightmare. Although I use a well designed server-side structure using DDD (application services, domain sevices, value objects,...etc.) I have had little luck structuring my client code to a better separation of concerns.

I'm not building a client-side application. I just use jQuery intensively for the client side.

How should I approach the code structure to apply DDD client-side wide?

share|improve this question

closed as too broad by GlenH7, Jimmy Hoffa, Kilian Foth, Robert Harvey, Dynamic Nov 23 '13 at 0:04

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Sounds like you could use an MVVM framework ( AngularJS, Knockout, ... ), when you include jQuery along with AngularJS it'll use jQuery instead of the jQLite which AngularJS has, so you still have jQuery.

What these kind of frameworks allow you to do is define actions on elements referring to controller methods. For example AngularSJ has the ng-click directive; This as opposed to selecting something with jQuery and then adding an event handler )

Also AngularJS allows you to separate your code into controllers, services, configs, etc. ( Im only referring to AngularJS here because I haven't worked with Knockout or any of the others. )

share|improve this answer
Knockout also contains special code that addresses jQuery being included, and it works nicely. It's a much lighter library that just does data binding, rather than a full blown framework like Angular. Knockout requires the user to do all the actual design themselves. – Benjamin Gruenbaum Sep 9 '13 at 10:17

I'm not building a client-side application. I just use jQuery intensively for the client side.

If your goal is gradual refactoring rather than a rewrite, I'd check out RequireJS, which (unlike all the other answers) is not an MVC framework.

Instead, it's just a way to break your code down into modules and to handle the dependencies between them. The mechanism for this is called "Asynchronous Module Definition", or AMD, which somewhat resembles the way classes in PHP or Java are typically organized.

Here's a ridiculously simple example:


// Define a module with no dependencies that is an array


// Define a module with one dependency on another module and is a function
    var f = function(){
        var num = Math.floor(Math.random() * quotes.length);
        return quotes[num];
    return f;


// Define a module which is an object. (Effectively a singleton)
    var o = {
        "getQuote" : generateQuote,
        "doPopup" : function(msg){alert(msg);}
    return o;


// Load a module for use by plain old procedural code

In this way you can start to chunk your existing code into whatever organization makes the most sense to you.

share|improve this answer

I would strongly recommend to use some kind of MV* JavaScript framework. There are a lot of them so (AngularJS, KnockoutJS, Ember, Backbone). Here is a nice review of some of the most popular ones.

Using a JS framework can sometimes be overkill for some simple pages without a lot of interactivity or if the pages relies heavy on server side. In those cases JS framework would probably not be a good fit. But if you're building something that is more complex (on the client side) and requires some interactivity (like frequent DOM manipulation or routing), the JavaScript framework is a perfect solution.

With client side frameworks you have half the job done for you:

  • Models that will represent your data.
  • Views that will update as you change your models.
  • Controllers that handle user input (and modify your Models).

Most of MV* frameworks also support unit testing and end-to-end testing (I love the way testing is supported in AngularJS). Unit tests on front end will ensure that your functionality doesn't break when someone changes something (e.g. some class was removed or changed and your jQuery selector can't find the element to add click event handler).

share|improve this answer

You can roll your own MVC if your site is fairly basic. Take a look at PureMVC and try to emulate that model. Get a pub/sub system such as radio then build this: A facade that registers all mediators, controllers and models. Given you know what the last two are, the mediator is basically the view/view component - but it abstracts it so you don't have to worry about the underlying html. Mediators receive and send messages. Oftentimes they can receive msgs from the model raw, so long as the data chunk isn't too huge. Other times you will need a controller to manage things. Controllers are stateless and spring into action on a given message. They manage the exchange between the model and the view. If you do everything right, the controllers are the most disposable as far as reuse. The other two are as dumb as possible.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.