# Mission — the "v2" architecture (Hexagonal + CQRS + sqlc)

## Who this is for
A strong backend/Go engineer on the Manabie platform who owns **conversationmgmt**,
**notification**, and **spike** — services that were (partly) rebuilt on the newer "**v2**"
architecture: **hexagonal (ports & adapters)** + **CQRS (command/query separation)**, with
**sqlc (typed SQL codegen)** as the query layer in eureka.

## Why learn this
Two reasons, pulling the same direction:

1. **Catch up on this repo.** "v2" is the shape all new code is written in — `modules/` with a
   `core/port` + `infrastructure` split (spike, notification, conversationmgmt) or
   `domain/repository/usecase/transport` layering (eureka). If you can't read a v2 module fluently
   — name the port vs the adapter, the command vs the query, where the SQL comes from — you can't
   move fast in your own services. This course makes the layout second nature.
2. **Interview readiness.** "Explain hexagonal architecture." "What's CQRS, and when would you use
   it?" "How do you keep the database out of your domain?" These are staple senior-backend
   questions. You'll answer them from the canon (Cockburn, Fowler, Three Dots Labs) *and* from real
   code you shipped — which is what makes an answer land.

## What success looks like
By the end you can:

- **Read any v2 module cold** and name each layer, the ports vs the adapters, and the dependency
  direction — in spike, notification, conversationmgmt, and eureka.
- **Explain hexagonal / ports & adapters** and *why* dependency inversion matters (swap adapters,
  test the core in isolation) — grounded in Cockburn's original.
- **Explain CQRS** honestly — the write-model / read-model split, Fowler's "adds risky complexity"
  caveat, and this repo's pragmatic version (folders + handler types, **no bus**).
- **Explain sqlc** — write SQL, generate type-safe Go — and read eureka's generated `Querier`,
  the `.sql` sources, and how a repo adapter wraps it.
- **Spot the smells** in your own code: the conversationmgmt dependency-inversion leak, the
  `pgtype` leak, the hybrid sqlc adoption — and say why they're smells.
- **Draw the whole flow** transport → usecase → port → adapter → SQL → DB, and place the CQRS
  read/write asymmetry on it.

## The through-line
This repo doesn't do textbook-pure v2 — it does *pragmatic* v2, and the honest bits are the most
instructive: **CQRS with no bus**, **sqlc adopted only in eureka (and only partially there)**, a
**core that leaks into infrastructure** in one of your own services, and a deliberate
**read-direct / write-through-a-port** rule. Learn the canon, then learn what this team actually
chose — and why. Every lesson lands on a real `file:line` from the code you own.

## Anchor & emphasis (chosen)
- **Emphasis:** *balanced* — teach each pattern generally, then this repo's take, then land it on
  your service.
- **Anchor:** *your own services first* (spike / notification / conversationmgmt) for hexagonal &
  CQRS; **borrow eureka** for the sqlc third (it's the only service that uses sqlc).