Clarification on the Use of UI Components Inside the Entity Segment in FSD

[masoudjapalaghi]

Hello everyone,

I’m working on a project using Feature-Sliced Design (FSD) and I have encountered a conceptual challenge regarding the use of UI components inside the Entity segment.

Traditionally, based on architectural patterns like Domain-Driven Design (DDD), Entities are considered responsible for the data layer and state management, encapsulating business rules and logic. The core principle behind Entities is that they should manage data and domain-specific logic without mixing concerns related to the presentation layer (UI).

However, in some FSD implementations, it’s suggested that UI components can exist within the Entity segment and be directly rendered as part of a feature. This seems to blur the line between Separation of Concerns and introduces a tight coupling between the data and presentation layers, which could contradict principles from architectures like Clean Architecture or Layered Architecture.

Could you provide clarification on why FSD allows this approach? What are the theoretical justifications or best practices that make placing UI elements inside the Entity segment a viable architectural decision? Additionally, how does this align with established concepts like High Cohesion and Loose Coupling in modern software design?

Thank you in advance for your insights and guidance.

[illright]

Hi, thanks for this detailed question!

The concern about introducing tight coupling of data to the UI is a very valid one, and in FSD we suggest to address it by not connecting the data to the UI component right away. The UI segment in entities is intended to store different visual representations of this entity that are reused across several pages. It's kind of like a skeleton — it has no data and little to no interactivity, and you plug all that in on higher layers like pages.

In terms of cohesion, I agree that it's not the best. The ideal here would be to colocate the representation of an entity with the rest of the page that it's used in. However, if this entity is an important business concept then it might be better to ensure that this entity is consistently visually represented across the app, at the cost of some cohesion.

Ultimately, it's a trade-off, and just like the idea of extracting the entities into their layer in the first place, I don't recommend doing it unless your current approach fails. Creating an entity introduces more complexity to your app's code, and opens the architecture up for misuse, as business entities are not a simple concept to grasp. I usually recommend colocating entity UI in Pages or Widgets.

[masoudjapalaghi]

Hi,

Thank you for your detailed explanation. I accept your reasoning for having a contract in Feature Slices Design (FSD) as it supports the conceptual integrity of the project developers. It's essential to maintain this coherence, even with the concerns about code cohesion.

I appreciate your insights.