Sitecore Helix – Modules that need to reference another module in the same layer Part 3

Modules that depend on each other

This is the last part in a 3-part series on dependency, if you have not read the previous posts please read Part 1 and  Part 2.

Implicit (Soft/Weak) Dependencies

So how is it possible to have 2 modules that depend on each other? Surely that would not compile, due to the circular reference, right? But it is possible to have implicit dependencies that is where the C# projects do have to reference each-other – but they depend/communicate using non-compiled methods (usually using a string identifier or guid id).

Implicit dependencies are not only limited to modules that only depend on each other, but all types of module dependencies.

Here is a list of possible sources for soft dependencies:

  1. Url’s
    • Query strings – i.e. q for search term.
    • Path i.e. /…/Electronics/…/ – i.e. the product type (metadata/taxonomy/categories/etc.) is in the path.
    • Host
  2. Sitecore
    • Template ids
    • Field names/id’s
    • Item paths
    • Sitecore queries
    • Lucen / Solr indexesSitecore string references
    • Pipeline parameters
    • Context
  3. Form data
  4. Session
  5. Cache’s
  6. Request items
  7. Configuration
    • Sitecore.config
    • web.config
  8. External systems (i.e. SQL database, ERP, CRM, etc.)
  9. Local storage

The most common examples of soft dependencies are query strings or using the field/path/template string identifiers from another module.

For example: Metadata is a typical example where soft dependencies creep in. The metadata module needs the title for a given item. So it uses the sitecore field id’s from the news module, blog module, product module, etc. to get the title from an item.


Within a blog post it is difficult to give a clear step by step approach and or an example with how to deal with this circular references, but here is a number of solutions.

  1. Consider that the modules boundaries/responsibilities are incorrect (see solution 1 in part 1).
  2. Introduce an Abstraction in the foundation layer and keep the concrete implementation in the feature layer (see solution 2 in part 1).
    • Slight modification – take the common functionality and move it to a new module in the feature layer and introduce an Abstraction in the foundation layer, for the remaining 2 modules to use.
  3. Each module defines an interface and then a introduce a class in the project layer (see solution 1 in part 2)

I normally recommend abstraction as the best tool to deal with dependencies. But when 2 modules are only dependent on each other, it is normally because the modules boundaries/responsibilities are incorrect as they are violating the Common-closure principle.

I hope this series on dependencies has been helpful 🙂


1 thought on “Sitecore Helix – Modules that need to reference another module in the same layer Part 3

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.