1b:I[288412,["/_next/static/immutable/chunks/22p29gwb96j-r.js","/_next/static/immutable/chunks/36h3b3-9blmzs.js","/_next/static/immutable/chunks/3c355-hwz2o9d.js","/_next/static/immutable/chunks/2d3m-k720jl5i.js","/_next/static/immutable/chunks/1cz1vzqlz0yhj.js","/_next/static/immutable/chunks/1eb739fc05qmz.js","/_next/static/immutable/chunks/0xd1eiu9_iw_y.js"],"WireframeBlogDetail"] 1c:T105c,

Vertical slice architecture flips that. You organize by feature, and each feature owns everything it needs.

One slice, everything inside

src/features/orders/
  actions/
    orders.action.ts
    index.ts
  components/
    orders-screen.tsx
    order-card.tsx
  hooks/
    use-orders.ts
  schemas/
    order.schema.ts
    index.ts
  store/
    orders.store.ts
  types.ts

Same shape for cart, rider, menu, and restaurant. app/ stays for routing only — pages just import from features/.

The one rule that keeps it clean: slices don't import from each other. When two features need the same thing, it moves to lib/ or components/shared/.

Schema lives in the slice

Validation sits right next to the feature that uses it — not in a global folder nobody maintains.

// features/orders/schemas/order.schema.ts
import { z } from "zod";

export const orderSchema = z.object({
  id: z.string().uuid(),
  restaurantId: z.string().uuid(),
  items: z.array(
    z.object({
      menuItemId: z.string().uuid(),
      quantity: z.number().int().positive(),
    })
  ),
  status: z.enum(["pending", "preparing", "on_the_way", "delivered"]),
  total: z.number().nonnegative(),
});

export type Order = z.infer<typeof orderSchema>;

Store lives in the slice

// features/orders/store/orders.store.ts
import { create } from "zustand";
import type { Order } from "../schemas/order.schema";

interface OrdersState {
  activeOrder: Order | null;
  setActiveOrder: (order: Order | null) => void;
}

export const useOrdersStore = create<OrdersState>((set) => ({
  activeOrder: null,
  setActiveOrder: (order) => set({ activeOrder: order }),
}));

Actions live in the slice

// features/orders/actions/orders.action.ts
"use server";

import { orderSchema } from "../schemas/order.schema";

export async function createOrder(input: unknown) {
  const order = orderSchema.parse(input); // validate at the boundary

  // ...persist and return
  return order;
}

The query hook ties it together

This is where the slice's pieces meet. The hook wraps TanStack Query, calls the action, and validates the response against the same schema — so nothing untyped leaks into your components.

// features/orders/hooks/use-orders.ts
import { useQuery, useMutation, useQueryClient } from "@tanstack/react-query";
import { z } from "zod";
import { orderSchema } from "../schemas/order.schema";
import { createOrder } from "../actions/orders.action";

const ordersKey = ["orders"] as const;

export function useOrders() {
  return useQuery({
    queryKey: ordersKey,
    queryFn: async () => {
      const res = await fetch("/api/orders");
      const json = await res.json();
      return z.array(orderSchema).parse(json); // validate at the edge
    },
  });
}

export function useCreateOrder() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: createOrder,
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ordersKey });
    },
  });
}

Components never touch fetch, the action, or the schema directly — they just call useOrders() and useCreateOrder(). Everything stays inside the slice.

Why it sticks

When a bug appears or something needs to change, you know exactly where the file is. When a slice grows too big, the boundary for extracting it is already drawn. And a new teammate can learn one slice at a time instead of mapping the whole repo at once.

It's more structure than a tiny project needs. But for anything team-sized, it keeps things calm.

6:[["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"BlogPosting\",\"headline\":\"Organize Next.js by Feature, Not by File Type\",\"description\":\"For a long time I organized Next.js projects the \\\"normal\\\" way — a big /components folder, a big /hooks folder, a big /schemas folder. It looks tidy, but every feature ends up scattered across all of them. Changing one thing means opening five folders.\",\"articleSection\":\"engineering\",\"image\":[\"https://res.cloudinary.com/dnye8vqwb/image/upload/v1788669104/Blogs/Blog_Banner_v2_p4e5rl.png\"],\"datePublished\":\"2026-09-06T04:36:38.011Z\",\"dateModified\":\"2026-09-06T04:36:38.120Z\",\"wordCount\":458,\"author\":{\"@type\":\"Person\",\"name\":\"Lorn Samnang\",\"url\":\"https://lornsamnang.com\"},\"publisher\":{\"@type\":\"Person\",\"name\":\"Lorn Samnang\",\"url\":\"https://lornsamnang.com\"},\"mainEntityOfPage\":{\"@type\":\"WebPage\",\"@id\":\"https://lornsamnang.com/blog/next-js-vertical-slice\"},\"url\":\"https://lornsamnang.com/blog/next-js-vertical-slice\"}"}}],["$","$L1b",null,{"post":{"id":"blog_X2Au9YZUplFzgL","profileId":"1","title":"Organize Next.js by Feature, Not by File Type","slug":"next-js-vertical-slice","excerpt":"For a long time I organized Next.js projects the \"normal\" way — a big /components folder, a big /hooks folder, a big /schemas folder. It looks tidy, but every feature ends up scattered across all of them. Changing one thing means opening five folders.","coverImage":"https://res.cloudinary.com/dnye8vqwb/image/upload/v1788669104/Blogs/Blog_Banner_v2_p4e5rl.png","content":"$1c","status":"published","category":"engineering","publishedAt":"$D2026-09-06T04:36:38.011Z","createdAt":"$D2026-09-06T04:36:38.120Z","updatedAt":"$D2026-09-06T04:36:38.120Z","deletedAt":null,"number":1,"total":2,"prev":{"id":"blog_6Jw8EGcp0IYiyP","slug":"vertical-slice-architecture-cqrs-in-nestjs","title":"Vertical Slice Architecture + CQRS in NestJS"},"next":"$6:1:props:post:prev"}}]]