"Should this be a layer or a module?" is the question the whole interview orbits, because the job title says layers and the guide you studied says modules. The honest answer is that a team toolkit is usually both, split along one line: layers ship app code and conventions, modules ship build-time behaviour and injected runtime. This page gives you the decision rule, the composition, and the architectural use of layers beyond "shared UI": one layer per domain.

Know

• What a layer is good at: anything Nuxt discovers by convention. Components, composables, utils, pages, layouts, middleware, plugins, server handlers, app.config, nuxt.config presets (modules, route rules, Vite options). Zero build tooling, hot reload, override by file placement.
• What a module is good at: anything that needs to happen at build time. Reading the file system, generating code or types (addTemplate, addTypeTemplate), transforming source (addBuildPlugin), reacting to hooks (pages:extend, nitro:config), registering things conditionally, validating options, printing warnings, adding DevTools tabs. See Module authoring.
• The rule of thumb: if it needs an if, it is a module. A layer cannot branch on the consumer's options; a module's setup(options, nuxt) can.
• Both, composed: the layer lists the module in modules and passes team defaults; the module does the machinery. Consumers see one extends entry. This is how design systems (@nuxt/ui is a module plus a set of conventions), content platforms and auth kits are typically shipped.
• Layers as architecture: the docs list "modular architecture and Domain-Driven Design patterns in large-scale projects" as a use case. One layer per domain (layers/catalog, layers/checkout, layers/account) gives each team its own pages, components, server routes and stores inside one deployable app, with the project as the shell.
• The costs of domain layers: one router and one Nitro server, so route paths and server/api paths must be namespaced by convention; one dependency graph, so a heavy library in one domain layer is in everyone's build; cross-domain imports are possible but should be forbidden by lint rules, or the "modules" are modules only on paper.
• Where a layer is wrong: conditional behaviour, generated code, transforms, anything versioned separately from the app's UI (a build-time tool used by non-Nuxt projects), and anything that must not be overridable by placing a file (security middleware that an app could accidentally shadow).

How it works

The composed toolkit as consumers see it:

export default defineNuxtConfig({
  extends: ['@team/nuxt-layer-base'],   // components, composables, presets…
  teamToolkit: { analytics: true },     // …and options for the module the layer brought along
})

export default defineNuxtConfig({
  modules: ['@team/nuxt-toolkit', '@nuxt/ui'],
  teamToolkit: { analytics: false, generateRouteMap: true },   // team defaults, app overrides
})

Domain layers inside one app:

apps/shop/
├─ nuxt.config.ts               extends: ['@team/nuxt-layer-base']  (auto-scans layers/)
├─ app/app.vue                  the shell
└─ layers/
   ├─ 1.catalog/
   │  ├─ app/pages/products/**  routes owned by the catalog team
   │  ├─ app/components/Catalog*/
   │  └─ server/api/catalog/**
   ├─ 2.checkout/
   └─ 3.account/

// Keep domains honest: a domain layer may import from the base layer, never from a sibling domain.
export default [{
  files: ['layers/*/**/*.{ts,vue}'],
  rules: {
    'no-restricted-imports': ['error', {
      patterns: [{ group: ['#layers/[0-9].*'], message: 'Cross-domain imports are not allowed; use the base layer or an event.' }],
    }],
  },
}]

Exercise

Be able to say