Office Block B, Ground Floor, Capital Park, Central Lane, Riverglen, Johannesburg, Steyn City +27 87 265 4965 support@engineers-oncall.co.za

Week 2 to Delivery

Home Week 1 Week 2+
Graduate Delivery Track

Use Week 1 discovery to build something real.

This kata takes you from a blank repository to a delivery-ready solution. You will learn architecture by shipping increments, defending your boundaries, and proving behavior with tests.

Week 1 Discovery Week 2 to Delivery
View Roadmap Create Repo
The Kata

Build Aquaman, a weekly water delivery subscription service.

Aquaman sells scheduled bottled-water deliveries to homes, offices, and retail customers. Clients subscribe to a plan, choose delivery days, pause when needed, and expect reliable weekly service. Drivers confirm deliveries, operations teams reschedule misses, and finance needs billing-ready delivery evidence.

Your job is to model that business in a codebase that tells the truth about the domain. If your folders scream infrastructure, you are doing it wrong. If your tests only cover controllers, you are doing it wrong.

Business Focus

What Aquaman must do

  • Manage subscription plans for weekly water deliveries.
  • Generate delivery schedules from subscriptions.
  • Pause, resume, upgrade, and cancel subscriptions safely.
  • Track successful, missed, and rescheduled deliveries.
  • Produce billing-ready delivery evidence.
Learning Focus

What you must prove

  • You can apply onion architecture without creating ceremony for its own sake.
  • You can make the folder structure scream subscriptions, deliveries, billing, and fleet.
  • You can write unit tests for business rules before adapters exist.
  • You can add integration tests when persistence and HTTP boundaries appear.

Mission by delivery day

Ship a small but defensible product slice, not a pile of endpoints. Every increment must leave the system in a runnable state with passing tests and a documented decision trail.

Screaming architecture

Top-level folders should expose the Aquaman business: `Subscriptions`, `Deliveries`, `Billing`, `Fleet`, `Customers`.

Onion architecture

Domain rules at the center. Application use cases around them. Infrastructure on the outside. Dependencies point inward only.

Testing discipline

Unit tests guard rules. Integration tests guard contracts and wiring. Demo only what the tests already prove.

Architecture Rules

These are the constraints that teach you.

1

Organize by capability

Do not start with `Controllers`, `Services`, `Repositories`. Start with `Subscriptions`, `Deliveries`, `Fleet`, `Billing`, and `Customers`.

2

Keep the domain pure

Entities, value objects, and business rules must not depend on EF Core, web frameworks, or external SDKs.

3

Test before adapters

The first green tests should prove subscription scheduling and delivery rules without any database or API running.

4

Integrate with intent

Only add integration tests once you introduce persistence, background scheduling, or HTTP endpoints that must hold together.

Repo Bootstrap

Start from a clean repository and make the shape honest.

Use C# (.NET) for this kata, with PostgreSQL as the persistence store. Keep the same architectural rules and testing expectations, and do not start coding features until the solution structure communicates the business language clearly.

aquaman/ README.md docs/ decisions/ src/ Aquaman.Subscriptions/ Domain/ Application/ Infrastructure/ Aquaman.Deliveries/ Domain/ Application/ Infrastructure/ Aquaman.Customers/ Aquaman.Billing/ Aquaman.Fleet/ Aquaman.Host/ tests/ Aquaman.Subscriptions.UnitTests/ Aquaman.Deliveries.UnitTests/ Aquaman.Host.IntegrationTests/

Bootstrap activities

  • Create a new repository and write a one-paragraph problem statement for Aquaman.
  • Add a `README` that explains the domain, architecture rules, and how to run tests.
  • Create module folders before code, and commit that structure intentionally.
  • Add a `docs/decisions` folder to record why you chose your boundaries and trade-offs.
  • Set up a solution/workspace and a test project before your first feature commit.

Starter questions

  • What is a subscription, and what invariants does it own?
  • Does delivery scheduling belong in `Subscriptions` or `Deliveries`? Defend your answer.
  • What value objects are worth creating on day one?
  • What business events should exist before any infrastructure work begins?
  • What would make this design hard to change in week four?
Week 2 to Delivery Roadmap

Build the system in increments that earn the next layer.

Delivery 1

Model the subscription core

Focus on domain language. Implement customers, subscription plans, weekly schedule preferences, pause windows, and activation rules as domain types.

  • Unit test subscription creation, invalid schedules, pause/resume behavior, and plan upgrade rules.
  • Keep all behavior in pure domain/application code.
  • Publish your first architecture decision note explaining the module split.
Delivery 2

Add delivery scheduling use cases

Introduce application services that turn active subscriptions into delivery jobs for a target week.

  • Generate delivery jobs only for active subscriptions.
  • Prevent duplicate weekly jobs for the same subscription and date.
  • Test the scheduler with clock abstractions and deterministic dates.
Delivery 3

Earn persistence and integration tests

Add repositories and EF Core/Npgsql PostgreSQL mappings only when the use cases are already proven in unit tests.

  • Add integration tests for saving subscriptions and generating delivery jobs against a real test database or faithful containerized environment.
  • Verify module boundaries still point inward.
  • Do not let entity configuration leak into domain types.
Delivery 4

Expose the operational slice

Add HTTP endpoints or command handlers for subscriptions, weekly dispatch views, delivery confirmation, missed deliveries, and reschedules.

  • Integration test the full request flow, including validation and persistence.
  • Add fleet assignment rules only if they improve business clarity.
  • Prove the operations team can see what to deliver this week.
Delivery 5

Demo, harden, and explain your trade-offs

Your final delivery is not just the code. It is the story of the system, the rules it protects, and the evidence that it works.

  • Prepare a live demo path: create subscription, generate weekly jobs, confirm a delivery, show billing evidence.
  • Present the architecture boundaries and why they matter.
  • Show which behaviors are covered by unit tests and which are covered by integration tests.
Increment Backlog

Do these in order. Each one must stay green.

A

Subscription enrollment

A customer chooses a weekly plan, delivery day, quantity, and start date.

Prove: invalid start dates, invalid quantity, and conflicting paused states are rejected.

B

Weekly schedule generation

The system produces delivery jobs for the next week from active subscriptions.

Prove: paused or cancelled subscriptions do not create jobs.

C

Pause and resume

Customers can pause deliveries for holidays or site closures, then resume safely.

Prove: resumed subscriptions only resume after the pause window closes.

D

Delivery confirmation

Drivers confirm delivered quantity, timestamp, and notes for each job.

Prove: completed jobs cannot be completed twice and missed jobs require a reason.

E

Missed delivery recovery

Operations can reschedule a failed or missed weekly delivery.

Prove: reschedules keep a trace to the original failed job.

F

Billing evidence

Finance can ask for a delivery summary for a subscription period.

Prove: only completed deliveries count toward billing evidence.

Testing Guidance

Know why each test exists.

Unit tests should prove rules like:

  • `Subscription_cannot_start_in_the_past`
  • `Paused_subscription_does_not_generate_weekly_job`
  • `Plan_upgrade_changes_future_deliveries_only`
  • `Delivery_job_cannot_be_completed_twice`

Integration tests should prove flows like:

  • Create subscription through the API and verify persistence.
  • Generate weekly jobs and verify saved delivery records.
  • Complete a delivery and verify billing evidence reflects it.
  • Pause a subscription and verify the next schedule generation skips it.
Activities

What you should physically do each week.

Individual activities

  • Create the repository yourself. Do not clone someone else's structure.
  • Write one architecture decision note per week.
  • Open pull requests for each increment with screenshots and test evidence.
  • Record one thing you simplified and one thing you deliberately deferred.

Pair activities

  • Review each other's module boundaries and naming decisions.
  • Swap test suites and explain what business behavior they prove.
  • Do one live refactor where you remove a leaky infrastructure dependency from the domain.
  • Run one demo where the other graduate acts as operations or finance.
Final Delivery Checklist

You are done only when you can defend the design.

Code

  • Capability-first module naming is clear.
  • Dependencies point inward.
  • The solution runs locally with documented steps.

Tests

  • Business rules are covered by unit tests.
  • HTTP and persistence wiring are covered by integration tests.
  • Tests are deterministic and readable.

Explanation

  • You can explain why each module exists.
  • You can explain why each test belongs where it does.
  • You can explain what you would build next if Aquaman grew.
Back to Week 1

Engineers-OnCallEngineers-OnCall

End to end cybersecurity and software engineering solutions driven by a security-first approach and local support across South Africa.

Get Started Graduate Week 1

Contact Info

Office Block B, Ground Floor, Capital Park, Central Lane, Riverglen, Johannesburg, Steyn City

support@engineers-oncall.co.za

+27 87 265 4965

Office Block B, Ground Floor, Capital Park, Central Lane, Riverglen, Johannesburg, Steyn City

Kata Outcomes

Repo bootstrap Increment roadmap Week 1 discovery Request review

Architecture Lens

Screaming architecture Onion boundaries Unit vs integration tests Aquaman kata

© 2026 Engineers-OnCall - All rights reserved.