Proposal: Add optional layer for infrastructure service

[noveogroup-amorgunov]

Overview

Hi! I'd like to revisit an idea I’ve frequently shared at meetups and which we’ve successfully implemented in one of our production projects. The proposal is to introduce a separate layer for infrastructure entities (infrastructure services, then just services).

Definition

By infrastructure services, I mean entities that are not part of the business logic but provide the technical foundation that supports and enables business logic. Each infrastructure service would be structured as a typical slice, including common segments (such as model, ui, lib, api and others).

Examples

Typical infrastructure services might include:

• Analytics systems
• Notification/modal/toast managers
• Event buses
• Application theme management
• Dynamic feature config
• Feature flag handling
• Alternative API providers
• User session management

Current Approaches (and Their Problems)

So far, I’ve identified three approaches, all of which present significant challenges:

1. Distribute Services Across Existing Shared Segments + app/providers

Example:

📂 app
  📂 providers
    📄 ThemeProvider.tsx
    📄 DialogManagerProvider.tsx
📂 shared
  📂 api
  📂 model
    📄 featureFlagsStore.ts
    📄 loadFeatureFlags.ts
    📄 changeTheme.ts
    📄 themeStore.ts
    📄 dialogStackStore.ts
  📂 lib
    📄 useCurrentTheme.ts
    📄 useDialog.ts
    📄 useFeatureFlags.ts
  📂 ui
    📄 AlertDialog.tsx
    📄 DialogPresenter.tsx
    📄 DialogPresenterWrapper.tsx
    📄 FeatureToggler.tsx
    📄 ThemeToggler.tsx

Cons:

• Leads to destructive decoupling — modules become fragmented and difficult to maintain.

2. Distribute Services Across shared/lib/*

Pros:

• Easy to implement.

Cons:

• The lib segment is designed for helper utilities, not services.
• Services get mixed with unrelated helpers.
• No clear boundaries between services.

3. Use Custom Segments in shared/*

Pros:

• Provides slightly more structure than the previous approach.

Cons:

• Services are full slices, not segments — this breaks the architectural principles.
• Services get mixed with other shared segments (api, ui, lib, config).
• Current linter settings (steiger) prohibit certain segment combinations (e.g., ui inside shared segment).

Proposed Solution

Introduce a New Layer: shared/services

Formalize infrastructure services as a separate optional layer, which contains first-class slices.

Example:

📂 shared
  📂 services
    📂 theme
      📂 lib
        📄 ThemeProvider.tsx
      📂 model
        📄 themeStore.ts
        📄 changeTheme.ts
      📂 ui
        📄 ThemeToggler.tsx

Advantages:

• Clear boundaries and separation of concerns.
• Consistent with Feature-Sliced Design principles — services treated as first-class slices.
• Enables standard slice rules, such as prohibiting direct cross-imports.
• Scales well as the number of services grows.

Potential Challenges:

• Add an additional layer, increasing cognitive complexity.
• Clear documentation will be needed to distinguish shared/services from shared/lib.
• Support this layer for steiger

Conclusion

Introducing the shared/services layer offers a scalable and maintainable solution to properly structure infrastructure services, while aligning with FSD principles.

What are your thoughts on this approach?

[illright]

Hi, thanks for writing up this proposal! It's definitely an interesting one and I agree that the current solution proposed by FSD is less than optimal

My main doubt is regarding consistency. If shared is a layer and shared/services is a layer, then what does that mean for the hierarchy of layer -> [slice] -> segment? Not to mention import rules. I would rather have this new layer on the same level as the others.

Another thing I'm worried about is — how many slices will a typical application have in this layer? You listed a bunch of examples of things that could go inside that layer, but an application develops over time, so there might be a long period where there are only 1-2 services, which might not justify an entire layer. Maybe we can do it so that services are segments in shared until it becomes inconvenient, and then you could extract the services into a separate layer

[noveogroup-amorgunov]

Hi, thanks for the feedback!

My main doubt is regarding consistency. If shared is a layer and shared/services is a layer, then what does that mean for the hierarchy of layer -> [slice] -> segment? Not to mention import rules. I would rather have this new layer on the same level as the others.

Regarding consistency, I agree that this layer would be better placed at the global level (like the other layers). However, I believe it still belongs to the shared part of the application (since local services can be kept within the corresponding slice). From this perspective, it makes sense to keep it inside shared/services or shared/infrastructure. This could also be reflected in the naming, for example as shared-services.

Another thing I'm worried about is — how many slices will a typical application have in this layer? You listed a bunch of examples of things that could go inside that layer, but an application develops over time, so there might be a long period where there are only 1-2 services, which might not justify an entire layer. Maybe we can do it so that services are segments in shared until it becomes inconvenient, and then you could extract the services into a separate layer

I totally agree that this layer will probably only be necessary for a small number of projects, and at the early stages it will likely be unnecessary. I also agree with the idea of keeping infrastructure services as segments within shared until there are enough of them to justify creating a separate layer.

In fact, I probably wouldn’t include this layer in the base recommended version at all. Instead, I’d treat it as either an experimental feature or include it in the methodology as part of an advanced usage section (which could later also include examples of expanding into a fractal architecture, the @x feature, and so on).

[Desteel]

First of all, I am not sure examples really show issues, because I definitely would not do this in any case

📂 app
  📂 providers
    📄 ThemeProvider.tsx
    📄 DialogManagerProvider.tsx
📂 shared
  📂 api
  📂 model
    📄 featureFlagsStore.ts
    📄 loadFeatureFlags.ts
    📄 changeTheme.ts
    📄 themeStore.ts
    📄 dialogStackStore.ts
  📂 lib
    📄 useCurrentTheme.ts
    📄 useDialog.ts
    📄 useFeatureFlags.ts
  📂 ui
    📄 AlertDialog.tsx
    📄 DialogPresenter.tsx
    📄 DialogPresenterWrapper.tsx
    📄 FeatureToggler.tsx
    📄 ThemeToggler.tsx

because it's the opposite of what we expect from fsd, and it's more about horizontal slices. In this particular example, in my opinion, all theme files should be located in ui/theme, there is no reason to distribute them. The same approach can be applied for most of cases like this. The question is rather how to properly organize the internal structures when you are doing this.

Anyway, I've already used the same approach in my projects as suggested, like

📂 shared
  📂infrastructure
    📄 api
    📄 persistence

and this works well. As @alright said, there may be inconsistencies with other parts of the shared, but I personally don't care about this, because in my mental model it still works well as part of shared, as well as other specific parts that you can involve in your project, like the shared kernel. The main thing is not to create new layers for everything that you don't know where to put it.

[noveogroup-amorgunov]

Hi, thanks for the feedback.

I am not sure examples really show issues, because I definitely would not do this in any case

I completely agree with this. It’s not what we typically expect from FSD, but I occasionally see projects that split infrastructure in this way. There are even some examples like this in the showcase: https://feature-sliced.github.io/documentation/examples

examples

• App theme in entity layer (entities/theme) as slice ( https://github.com/UmttikhinaDasha/IT-Bookstore/tree/main/src/entities/theme )
• App theme in app layer (provider) as slice ( https://github.com/penteleichuk/Moke-Smoke/blob/main/src/app/providers/ThemeProvider/model/slice/themeSlice.ts ) and shared/lib/theme with additianal code ( https://github.com/penteleichuk/Moke-Smoke/tree/main/src/shared/lib/theme )
• App theme with store in shared/lib/theming ( https://github.com/pijng/moonlogs/blob/master/web/src/shared/lib/theming/index.ts )
• Modal manager in shared/modal as segment ( https://github.com/falkomerr/falkchat/blob/master/src/shared/model/modal-store.ts ) and provider in app/providers ( https://github.com/falkomerr/falkchat/blob/master/src/app/_providers/modal-provider.tsx ).

I think all examples are valid, but this difference in implementation occurs because there is no single place to host common infrastructure services. And everyone does it their own way.

In this particular example, in my opinion, all theme files should be located in ui/theme, there is no reason to distribute them. The same approach can be applied for most of cases like this. The question is rather how to properly organize the internal structures when you are doing this.

This might be a valid solution, but as far as I know, according to the methodology, we cannot nest segments within other segments. @illright, what do you say about this?

📂 shared
  📂 ui // segment
    📂 theme // like a slice not allow right now
      📂 model
      📂 lib
      📂 ui
      📄 index.ts

Maybe it’s worth considering in this way and allowing the creation of nested slices... here they go again :)

The same approach can be applied for most of cases like this

That’s actually how we started working at first. Some infrastructure services were placed in shared/lib/*. Others were moved to the entity layer, since our team agreed that the app theme, feature flags, and user session were considered entities in the context of the frontend application. This worked quite well until the number of infrastructure entities grew too large (around 30–40 full slices).

As @illright said, there may be inconsistencies with other parts of the shared, but I personally don't care about this, because in my mental model it still works well as part of shared, as well as other specific parts that you can involve in your project, like the shared kernel. The main thing is not to create new layers for everything that you don't know where to put it.

I completely agree with you.