Best architectural pattern to avoid module dependencies on Feature layer

Question

I would like to get some advice on architectural pattern to avoid module dependencies on Feature layer.

Every site has some sort content page like article or news. Those can be managed as Feature/article module Or Feature/news module. Both has common fields like title, summary and image.

Now I have created a Feature/FeaturedContent module. In which I have a slider with its own templates. But the content author want to choose and pick items from Article or News section where only the title, summary and image will be used.

Hook up the items from different module is easy but when I render it with @Html.Sitecore().Field(Templates…. I will not have those fields(title, summary and image as the ID of those fields are different in each module) on my Feature/FeatureContent template. And I can't not make reference to other module under Feature layer. And I can't not add those fields as those fields are not belong to FeatureContent module. This is because Helix are not allowed to have dependence between modules under Feature layer.

I would like to get some advice on how to work around this. I would certainly like allow the content author to reuse content from different feature module. I would think I have to move the common fields into foundation. Any advices are highly appreciated. Thanks

Answer 1

Firstly, it's discouraged, but not impossible to have some inter-dependence in the Feature layer. Obviously this affects module coupling, so should be avoided where-ever possible.

In your particular case I think the approach should be to create a common base Feature with an "interface marker template" containing the 3 common fields you require, and the supporting Glass base classes (or other such ORM code). This module would then become a dependency to both the Article and News features.

While this is technically still a coupling issue, it still fits well into our SOLID principles, and it's still top-down in a sense. It might be tempting to mark this as a Foundation module but it really isn't so I would discourage that thought (in case you were going to have it). Think of this as an internal sub-layer in the larger Feature layer