Helix Best Practice when developing components for the Marketplace

Question

So I've been planning to develop some modules for the community to place in the marketplace but also as code on GitHub that people can extend from.

Having said that, I'm hoping to develop these modules using the Helix pattern, but I'm running into a question often from an architectural standpoint. If I develop a "Feature" does it belong in Feature or Foundation.

I'm still fairly new to Helix, this would be an easy question to answer if it was for one of my own projects (it would be Feature), but since this is likely to be something someone else pulls in and potentially extends, wouldn't it make more sense in the Foundation?

Answer 1

Although the Helix documentation does cover this, I guess it's a big pill to swallow all at once so here are a few simple guidelines to help you on the Helix path:

Foundation module
This acts as an API to Feature modules.
The Foundation does not contain any form of presentation!

Feature module
This contains logic and presentation, but never styling.
So presentation is usually in the form of semantic HTML so it can be styled per Project module.
Feature modules may reference Foundation modules.

Project module
I guess you would typically not include this in a Marketplace package as this is the site-specific stuff, but you could add a demonstration project, for example to explain how the module could be styled.

In reference to Richard's answer:

Foundation
Modules that are really CMS based. So a control panel, some admin interface etc..

Feature
Modules that obey the Common Closure Principle

I do not agree with this; The fact that it's a control panel or admin tool does not indicate whether or not the module contains presentation.
Features do not have to be client (front-end) features!
You could say that if the module is exposed to a user (whether that is a content editor or a site visitor, doesn't make a difference) it's a Feature module.

Also, the Common Closure Principle applies to all the modules in the Helix architecture, not just the Feature modules!

For example: Take a look at the MultiSite module in the Habitat example.
This module is contains both Feature and Foundation projects.
The Feature project contains the stuff that is exposed to the user.
The Foundation project contains the stuff that is used by the Feature project and may be used by other Feature projects as well.

TLDR; Your Marketplace module can contain both Feature and Foundation projects. It does not necessarily have to either a Feature or a Foundation project.

Answer 2

I think it really depends on your module. So this question could be quite broad.

My high level thoughts would be:

Foundation:

• Modules that are really CMS based. So a control panel, some admin interface etc...
• Modules that are for presentation but are not a self contained feature, like the Sitecore.React module

Look at the category you are going to add your module too, if you are putting it in Administration its probably a Foundation module

Feature

When are creating a Client Feature or something that will be used in presentation it can be harder to place. I would say

• Modules that are self contained and can be used with or without customizing
• Modules that obey the Common Closure Principle

From the helix docs this means:

This principle ensures that changes in one feature do not cause changes anywhere else, and that features can be added, modified and removed without impacting other features.

So as long as your module obeys that, it can be a feature, otherwise make it a Foundation module.

What if it crosses over?

What if your module has sections that are self contained presentation parts, and also shared elements. There is nothing to say you can't have parts of your module that are Feature layer and parts that are Foundation - approach it the same way you would a client solution.