Project structure

Standard application

aponia new creates a flat starter layout:

my-api/
├── .env.example
├── .gitignore
├── aponia.json
├── package.json
├── README.md
├── tsconfig.json
├── vite.config.ts
├── src/
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   └── main.ts
└── test/
    └── app.e2e-spec.ts

The root AppModule, controller, and service remain directly under src. The CLI does not create an artificial src/modules/app directory.

Feature directories

Later features belong directly under src/<feature>:

src/
├── app.module.ts
├── main.ts
└── greeting/
    ├── entities/
    │   └── greeting.entity.ts
    ├── greeting.controller.spec.ts
    ├── greeting.controller.ts
    ├── greeting.model.ts
    ├── greeting.module.ts
    ├── greeting.service.spec.ts
    └── greeting.service.ts

A REST CRUD resource generates the entities/ and *.model.ts files shown above; the model file holds the @Validation() classes the controller uses in its route slots. A plain aponia g controller or aponia g service generates only the matching file and its spec.

Keep feature-owned controllers, services, modules, validation models, entities, and tests together. Create top-level common, config, or database folders only for code genuinely shared by multiple features.

File responsibilities

Use the CLI generate reference to add files to this structure.