Question Investigation 7 What exactly is Vertical Slice Architecture - herougo/SoftwareEngineerKnowledgeRepository GitHub Wiki

Source 1: ChatGPT

Questions

1. What's the difference between software architecture and folder structure?

• Learnings:
  • Software Architecture focuses on:
    • System components (e.g., UI layer, business logic, data layer, external services).
    • Communication patterns (e.g., REST API, message queues, events).
    • Design paradigms (e.g., layered architecture, microservices, event-driven).
    • Non-functional requirements (scalability, performance, maintainability, security).
  • Folder Structure focuses on:
    • Where code is placed in the file system

2. Take the vertical slice architecture. What makes it more than a simple folder structure?

Main point: features as folders vs individual units (high cohesion, low coupling between features)

Aspect	Just a Folder Structure	Vertical Slice Architecture
Organization	Files grouped together for convenience	Features grouped as autonomous units
Boundaries	No enforced isolation between features	Strong boundaries, controlled dependencies
Coupling	Risk of cross-feature leakage	Promotes loose coupling, high cohesion
Evolution	Refactors into spaghetti if unchecked	Encourages scaling by adding new slices, not modifying existing ones
Conceptual model	Navigation aid	Architectural principle of how the system evolves

So the essence is: 👉 Folder structure = where code lives. 👉 Architecture = the rules and principles that dictate why code lives there, how it interacts, and how the system evolves safely.

3. Suppose I organized my code base at a high level by feature folders. In what cases would this not be considered vertical slice architecture?

Suppose I organized my code base at a high level by feature folders like so.
features
- to_do_items
  - controllers
  - validators
  - repositories
  - entities
  - services
  - core
- settings
  - ...
In what cases would this not be considered vertical slice architecture?

Answers

• Closer to VSA: features/to_do_items/add, features/to_do_items/get
• In VSA, each slice should be as self-contained as possible. If your to_do_items feature depends heavily on a shared core service or tightly couples with other features (e.g., settings), then you’re leaning back toward a layered monolith.
• Shared libraries/utilities are fine, but the business logic of one slice should not require peeking into another slice’s internals.

4. I would like to implement a vertical slice architecture for my JIRA clone dashboard application. What if I have queries/commands in feature X and Y, and they need to be used as dependencies for a new feature Z?

Possible Solutions:

• User a Mediator pattern (preferred)
• Extract Shared Logic into a Lower-Level Service/Library
• Duplication (e.g. small queries like GetUserById)
• Move sequential logic higher up (e.g. to a controller)

5. From my understanding of vertical slice architecture, individual slices should correspond 1:1 to use cases. However, real software and requirements are not this clean. There are dependencies all across different areas of code. So, why try to be so fine-grained with how we define slices? Am I misunderstanding vertical slice architecture?

• the slice is the primary unit of organization.
  • The slice says: “Here is the complete flow for Reset Password.”
  • Even if 75% of the code is in shared abstractions, the orchestration logic (the what and when) stays in the slice.

6. In vertical slice architecture, do you split a UserRepository into UserCreateRepository and UserUpdateRepository?

• Short answer: yes

7. Code Review of https://github.com/herougo/twitter-clone/blob/main/twitter-backend/src/persistence/repositories/MessageRepository.js

• The MessageRepository should handle simple CRUD of its own model (i.e. not use channelRepository.addLastMessage)
• The slice handler should handle the co-ordination of both repositories

8. I was told that in vertical slice architecture, UserRepository should be broken up into UserCreateRepository, UserUpdateRepository, etc. Doesn't this bloat the amount of dependencies in dependency injection?

• Not really, DI frameworks are designed to handle many registrations cheaply.