Skip to main content

5. Domain, Conventions & Your First Changes

Goal for this page: understand the domain the app models, follow our naming and structure conventions, know how code ships, and then make a few changes locally to prove it all connects.

Step 5.1 — The domain model: Standard Categories​

What & why: AquaGen is a water/energy monitoring platform, and almost every feature is organized around Standard Categories — a hierarchy of Standard Category → Services → Subcategories → Units (with six standard category types like Source/Consumption). You cannot reason about features without this model.

Learn:

Your task: In your own words, write out the category → service → subcategory → unit hierarchy with one real example. Then find where category data shows up in the running app.

Step 5.2 — Naming conventions & folder structure​

What & why: Consistency is what keeps a large monorepo navigable. Match the existing conventions — library layout (libs/{feature}/src/...), where stores/components/services go, the @aquagen-mf-webapp/... import aliases, and file/component naming — rather than inventing your own.

Learn:

Your task: Document the "shape" of a feature library: given a new feature foo, where would its store, components, services, and routes go, and what would they be named? Confirm your answer by comparing against two existing feature libraries.

Step 5.3 — Deployment & environments​

What & why: Know how your code reaches users before you ship it. The main production app deploys via CI to Azure, while other apps deploy elsewhere (e.g. Firebase hosting), and there are multiple environments.

Learn:

Your task: Identify which environment the app you ran locally points at, and how a merge to the main branch would reach production.

Step 5.4 — Make a few changes locally​

What & why: The fastest way to consolidate everything above is to change the app and watch what happens. Do this on the branch you created in Setup & Monorepo, Step 1.3 — all local, nothing pushed to main.

Do this — try two or three small experiments, e.g.:

  • Change a label or a value in one feature's components/ and see it update in the running app.
  • Add a console.log in a feature's dataSource/ and watch it fire when you open that screen.
  • Tweak a piece of state in a store/ and observe how the UI reacts.
  • Run the checks before you'd ever open a real PR: npx nx lint <project> and npx nx test <project> (see the Commands Reference).

Commit each experiment locally so you can git diff and, if needed, git restore to undo it.

Your task: Make at least two local changes across different layers (components / dataSource / store), run the lint/test targets for that project, and confirm the app still works. Jot down anything in this track that was unclear or out of date — that feedback is the most useful thing you can bring to your lead.

When you're ready for a real task

Once you're comfortable, ask your lead for a "good first issue." Then follow the standard flow — branch → small commits → pull request → address review → merge. That's your first real contribution; this page was the rehearsal.

You're onboarded 🎉

You can run the app, navigate the monorepo, trace routing/permissions/state, reuse the component and API layers, reason about the domain, follow our conventions, and change the code confidently on a local branch. Keep the Web Application docs handy as your day-to-day reference.