Refactoring jQuery spaghetti code to use DDD [closed]

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. )

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:

myapp/quoteList.js

// Define a module with no dependencies that is an array
define([],function(){
    return(["Hello","World"]);
});

myapp/generateQuote.js

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

myapp/MyUtils.js

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

page.html

<script>
// Load a module for use by plain old procedural code
require(["myapp/MyUtils"],function(MyUtils){
    MyUtils.doPopup(MyUtils.getQuote());
});
</script>

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

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).

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.