01Keep team rules in application services
TeamService checks membership limits, duplicates, valid names, and ownership. Centralizing those rules gives API callers a consistent result and makes the rules directly testable.
All selected work
02 / Full-stack development
Pokémon Team Builder
Domain rules, from interface to database.
The developed application combines a searchable Pokédex, account-scoped teams, team analysis, EF Core persistence, and a Docker Compose setup with SQL Server.
Development build. Implementation is on a development branch; public hosting and CI remain on the roadmap.
The problem
A team builder needs more than a list of Pokémon. It needs a consistent set of rules: private ownership, a maximum of six members, no duplicate members, and useful analysis of the resulting team.
How it fits together
An Angular client talks to ASP.NET Core controllers. Application services enforce team rules and calculate analysis, repositories handle persistence through EF Core, and SQL Server stores the data. A bounded-concurrency PokeAPI client supplies Pokémon data.
ARCHITECTURE SKETCH↗
01
AngularInterface & interaction
CLIENT↓authenticated requests
02
ASP.NET CoreOwnership · rules · analysis
API↓EF Core repositories
03
SQL ServerTeams & Pokémon data
DATAAngular UIASP.NET Core APIApplication servicesEF Core → SQL Server
Decisions & tradeoffs
02Scope operations to the signed-in owner
Team lookups compare the owner ID and treat another user’s team as nonexistent. Authentication and ownership are separate responsibilities: a signed-in user still needs access to a particular resource.
03Make analysis a separate concern
TeamAnalysisService evaluates defensive type matchups and summarizes stats. It builds on the same owner-scoped team service rather than duplicating access logic.
Validation & evidence
Evidence from the project’s implementation, test harnesses, and recorded status.
- Backend tests cover team rules, ownership, type effectiveness, seeding, and analysis.
- The Angular client includes service specifications for authentication and team operations.
- Docker Compose describes the frontend, API, and SQL Server development setup.
Current scope
The linked development branch contains the implemented application; the default branch is an earlier scaffold. Public hosting and CI remain on the roadmap. In-memory EF tests cover service rules; database-backed tests are the next step for SQL Server-specific behavior.
The next engineering step
Run the two-user ownership journey against SQL Server, add database-backed checks where appropriate, and verify a reproducible hosted demo.
Back to selected work
NEXT CASE STUDYGame Boy Emulator