Sitecore - Module based approach

​Okay so this is something I picked up from a recent developer group thingy and have been annoying my colleagues about this since then.

Instead of thinking Sitecore as one project (MVC) solution why not treat it like a module/deliverable based implementation.

I have created a sample solution which is here: https://bitbucket.org/ali_nahid/sckitchensync

 

The idea is pretty simple (Just like DDD pattern):

You get a rough idea of the entire implementation like what are the deliverable, functionalities etc etc and group them. Then just like the way you plan renderings on your page you plan bunch of different modules to implement in your solution.

In my case I divided my sitecore implementation into the following modules:

1.      The core:

This module contains the layouts and core renderings. In my case

1 standard layout that just defines the top level placeholders. Like header, footer, content etc.

And a “_MainContent” rendering that defines the other placeholders like bodycontent, bannerimage

And obviously the header, footer type of things that are going to be pretty much same throughout the entire site.

I’d give this task to “Gru” the evil genius.

2.      The Meta:

This module only handles the meta content (google meta, facebook meta, perhaps some GA code etc) of the site.

Let’s say “donny” the minion does it.

3.      The Navigation:

This module handles anything to do with site navigation like top navigation menu, breadcrumb, footer menu etc.

Let’s say “dave” the minion does it.

4.      The Imagery:

This module handles thing like “Banner”, Background, Carousel etc.

Let’s say “carl” the one eyed minion does it.

Each of these modules deal with their own set of sitecore renderings.

Interesting thing about this approach is these modules are MVC projects of its own. Sitecore is not restricting you from doing so. Who said only one MVC project for one sitecore website?

Ofcourse the "Domain POCOs" and "Service" and "Repository" layer concept exists as it is. And you can either separate them as per module or have them in their own projects is a personal preference.

 

Visualizing the above description:

instead of doing this:

We do this:

The few pros about this approach I could think of are:

1.      It can be very efficient in doing something like the following:

So you deliver a basic site with “Core, Navigation” module. Then you install/put “Imagery” Module. Then “The fancy” looking landing page module. And so on.  Each of these deliverable are independent to each other. So very less chance of breaking one while delivering the new feature because they’re all separate set of dlls.

 

2.     Easy to distribute work:

As per description each minion can take care of and be responsible for each module. This can come in handy to track progress.

3.      Once done maintaining becomes easier:

Because if something goes wrong or some changes required to make to the, for example Imagery module, you only look into “KitchenSync.Imagery.MVC” project as opposed to be bombarded by a massive MVC project.

4.      Creates a repository of re-usable components/modules. So there can be “Oakton sitecore repository” where you can search and download a module.

For example you need a navigation on your project download the navigation module from the repository.. you probably will need to made the tweak in the cshtml file to match the markup but the logic of how the navigation work remains the same. As a result you save yourself from creating bunch of sitecore renderings and classes.

5.      If gets follow through then this approach enforces a consistent culture of naming convention, field definition etc.

For example, on a page there’re often commonly 2 fields that exists. A summary and a description. Some calls it Short Description, Long Description and some calls it Summary and Description. Why not agree to one. They both mean the same.

6.      Testing is easier too. As you are testing one module at a time.

 

If you’re worried about how you launch it with IIS if there’re multiple MVC projects in the implementation, that’s not an issue either. So this is what I have done:

I have a typical sitecore installation which my IIS is pointing to and I am treating it as publish directory. My build settings puts the dlls to the publish directory /bin location so they become available to sitecore.

Then a simple powershell script copies the views to the publish directory’s Views accordingly. This script can be hooked to a VS post publish (I still don’t know how to do it)

Demo Video : https://youtu.be/rvhG8BQ6sPs

So what you think? Worth it not Worth it?