Backend-практикум: разбираем предметную область и первую версию приложения

Summary (technological concepts / product & code features)

1) Workshop goal and iteration strategy (“backend practicum”)

• The speakers set up a training approach for building a backend for a specific subject area (domain) when the team has little/no experience with similar apps.
• They intentionally start with a solution that is fully functional but poorly designed, then iteratively refactor one selected aspect per lesson.
• In each lesson:
  • They show the current code.
  • They explain what and why was improved.
  • They emphasize partial refactoring rather than rewriting the whole application.
• Participants are invited to clone the GitHub repository and improve the same focused part independently; later they compare results.

2) Architecture/tech choices (current “bad but working” baseline)

• The baseline uses domain-driven design (DDD) as an idea, but in the current version it’s described as an intentionally unsound implementation.
• There is also mention of a mindset gap (e.g., “No Stack” context), with the key point being a planned move toward better structure.
• The baseline application is an ASP.NET Core web API with:
  • Many controllers implementing CRUD-like behavior.
  • Business logic spread across controller actions (explicitly criticized later).
  • Direct database interaction inside controllers.
  • A static provider/service-locator-like setup for obtaining a DB connection string (dependency injection not properly used).

3) Database layer / ORM and schema

• The app uses a lightweight database library described as “white” (likely SQLite, possibly via a library such as Dapper or an EF alternative; subtitles are noisy).
• Key implementation details:
  • The database schema is initialized from code.
  • Inheritance mapping follows a table-per-class approach:
    • Base table for Animal
    • Separate tables for Cat and Dog (inherit from base via parent/IDs)
  • Additional tables:
    • Breeds (linked to animal type)
    • Food (linked to animal type)
    • Feedings (feeding history: animal, food, time, quantity)
• Feedings store timestamps as text, requiring formatting/parsing on input/output.

4) Controller patterns and query behavior (how API works today)

• Controllers follow a repetitive template with common patterns:
  • Create/open a DB connection inside the controller action.
  • Start a transaction with a chosen isolation level.
  • Use parameterized queries (filters built conditionally without raw user input concatenation).
• Filtering/search capabilities via SQL WHERE conditions:
  • Listings support filtering by animal type
  • Listings support search by name/nickname

5) Subject area implemented (animals domain)

The demo domain is domestic animals:

• Animal types: only Cats and Dogs
• Animal attributes:
  • nickname (unique per animal type rule)
  • breed (cat breed or dog breed)
  • Cat-specific: weight, gender
  • Dog-specific: tail length
• Breeds:
  • name
  • unique per animal type
• Food:
  • name and animal type (cat food vs dog food)
  • quantity (stock on hand)
• Feeding history:
  • must record who/when/what/how much was fed
  • feeding decreases food stock; there’s also replenishment logic

6) Functional requirements & API methods (implemented in repository)

The repository provides API endpoints such as:

• Add breed
• Get breeds with filters:
  • filter by animal type
  • search by name
• Add food (mentioned as “kohma” in subtitles = food)
• Get food with filters:
  • filter by animal type
  • search by name
• Add animal
• Get animal list with filters:
  • filter by type
  • search by nickname
• Get full animal info including feeding history
• Feed an animal:
  • record feeding
  • decrease food quantity
• Add/replenish food quantity:
  • increase stock

7) Frontend/manual testing (simple UI)

• The API is run with a simple frontend for manual testing.
• Demonstrated flows:
  • Create breeds
  • Create food (cat food / dog food)
  • Increase food quantity
  • Create cats with nicknames and breed/attributes
  • Feed animals and verify:
    • feeding history appears
    • type constraints are enforced (cats only accept cat food, etc.)
• UI nuance:
  • Search by Russian strings is case-sensitive (e.g., “snow” lowercase won’t match uppercase/correct casing).

8) Explicit critique of the current solution (why it’s intentionally “bad”)

When asked “what’s wrong / why not leave it,” the speakers highlight:

• Business logic smeared across controller actions, including:
  • validation steps executed as separate DB commands inside actions
  • repeated patterns (checking existence/uniqueness, ensuring sufficient stock, ensuring compatibility between animal type and food type)
• Broad SOLID violations:
  • controllers handle connection management, transactions, mapping DB rows to objects, and business rules
• Dependency inversion is criticized:
  • a static provider / service-locator-like global access supplies connection string and related dependencies.

9) What they will improve next lesson

• Next iteration focus: move business logic out of controllers into a more centralized domain/service layer.
• Specifically, extract logic such as:
  • “Can we create an animal with this nickname/breed?”
  • “Is food compatible with the animal?”
• They plan DI improvements and a cleaner separation, but postpone broader infrastructure/testing changes.
• They mention DDD concepts lightly for the next step, in a simplified form.

10) Testing plans (later)

• The recording suggests unit/integration testing may be discussed later.
• For the upcoming iterations, they do not focus heavily on testing changes yet; the immediate goal is code structure around business logic.

---

Main speakers / sources

• Konstantin Rozhkov — team lead (main presenter; explains workshop format and next steps)
• Mikhail Kulikov / Mikhail Kirikov (subtitles vary) — senior developer (demonstrates repository, code structure, and current implementation)
• Source references: GitHub repository for the workshop project (mentioned multiple times as the code base to clone/run)