Episode goal: teach the definition/implementation split concretely, using the file layout, so the viewer can recognize (and defend) the boundary.
Cold open
On camera: “Ask five engineers what a service is and you’ll get five answers. Here’s the one that makes everything else fall into place: a service is a contract, not a codebase.”
Principle
Voiceover: “Consumers should depend on what a service promises, never on how it keeps the promise. That’s the Dependency Inversion Principle. Chenile makes it something you can see in the file system.”
On screen
Reveal the two-module tree:
s1-api (model + interface) and s1-service (configuration, healthcheck, impl). Highlight the arrow: s2 → s1-api, with a red X on any arrow to s1-service.Voiceover
“The
api module is pure contract — the interface and the model. No implementation, no transport, no framework. It’s the smallest thing a caller needs. The service module implements that interface — and nobody depends on it.”Demo
Open
S1Service.java in api, then S1ServiceImpl.java in service. Point out the impl is almost empty — one business line. “No auth. No logging. No tenant lookup. That’s deliberate.”Health check
Show
S1HealthChecker. “Every Chenile service ships a deep readiness probe, so an orchestrator can decide when to route traffic or recycle an instance.”The seam
Voiceover: “Chenile customizes the controller so a service is declared to the framework, not just exposed. That declaration creates a seam around each operation — and that seam is where all the horizontal stuff will attach. No policy ever has to live inside the implementation.”
Key line
Lower third: “Depend on
s1-api. Never on s1-service.”Cliffhanger
“Next episode we generate this from scratch and run it — then we start filling that seam with policies.”
Recap card
“A service is a contract. Definition in
api, implementation in service, dependencies point at the abstraction.”Companion reading: Separate the service definition from the implementation