Brand specific features in Helix architecture

Question

Our site currently has a Search feature, similar to that in Habitat:

Feature
    Search
        Controllers
        Scripts
        Views

We're launching several new branded versions of our site, where Search looks and works differently for each brand. Do I create a new feature for each brand?

Feature
    Search
        Controllers
        Scripts
        Views
    CarSearch
        Controllers
        Scripts
        Views
    AeroplaneSearch
        Controllers
        Scripts
        Views

1. Is this a good idea? Is having brand specific naming like 'Car' and 'Aeroplane' going about things the wrong way?
2. If AeroplaneSearch has different Scripts and Views but uses exactly the same controllers as the original Search feature, should I duplicate the controller code, or perhaps push the controllers down to a Foundation layer project?

Answer 1

If the difference between each brand is just UI related, I would put a put a new search view, for each brand, in the project level. And use the data model and services from the feature level.

If you are required to write all new code for each brand. Spend some time understanding those differences and see if you can refactor your code down so the differences can be achieved by passing in custom predicates and models. This would allow you to keep search in the feature level and have the custom predicates in the project level.

If all that fails and the differences are too great to share code, I would put the different search projects in the project level.

The project level is for site specific one-off functionality. You just need to understand exactly how unique is each new search requirement.

Spend some time and look at how Habitat uses its search service. Each Feature passes in the requirements like templates, facets and search terms into the Foundation layer. This allows you to now have to rewrite search code in each feature.

public class NewsIndexingProvider : ProviderBase, ISearchResultFormatter, IQueryPredicateProvider
{
    public Expression<Func<SearchResultItem, bool>> GetQueryPredicate(IQuery query)
    {
        var fieldNames = new[] {Templates.NewsArticle.Fields.Title_FieldName, Templates.NewsArticle.Fields.Summary_FieldName, Templates.NewsArticle.Fields.Body_FieldName};
        return GetFreeTextPredicateService.GetFreeTextPredicate(fieldNames, query);
    }

    public string ContentType => DictionaryPhraseRepository.Current.Get("/News/Search/Content Type", "News");

    public IEnumerable<ID> SupportedTemplates => new[] {Templates.NewsArticle.ID};

    public void FormatResult(SearchResultItem item, ISearchResult formattedResult)
    {
        var contentItem = item.GetItem();
        if (contentItem == null)
        {
            return;
        }

        formattedResult.Title = FieldRenderer.Render(contentItem, Templates.NewsArticle.Fields.Title.ToString());
        formattedResult.Description = FieldRenderer.Render(contentItem, Templates.NewsArticle.Fields.Summary.ToString());
        formattedResult.Media = ((ImageField)contentItem.Fields[Templates.NewsArticle.Fields.Image])?.MediaItem;
        formattedResult.ViewName = "~/Views/News/NewsSearchResult.cshtml";
    }
}

Answer 2

Features in Helix are set of components serving a similar functionality or range of functionality. "Search" can be a folder inside Feature but all functionality related to search then should stay within it. You can have multiple actions in one controller returning different views. If you look at Habitat, it has one "Search Contoller" with various action results like: "Global Search", "SearchResults" etc.

Answer 3

We went through this with navigation. Decided to keep just Feature-Navigation and put all the different types of navigation under there. We named things so it would still make it easier to find what you needed. Things could get a little unruly if you break things up more, but you can do that if it makes sense to you.