feat: add basic academic teacher api

[Aleks334]

Changes

• create AcademicTeacher domain aggregate root with constructor validation of invariants
• add new api endpoint for quering basic academic lecturer data (without consultations, conducted courses, timetable and opinions)
• handle unique url slugs (for academic teachers profiles) created from name + usos id on backend with value object. See here what value object is: 1,2
• remove unused code in domain
• use private constructors in domain entities (for object hydration from db performed by ef core) and enforce existing entities instantiation through static factory method (this also improves code semantics). Thanks to @WiktorSinkiewicz for pointing me out advantages of using private constructors with ef core.
• fix: use IUnitOfWork interface in app layer to save changes within transaction instead of adding this method to each repository interface (implementation is the same for every repo, db context already implements unit of work pattern). For me using interface is better than db context directly due to easier mocking in unit tests and architectural reasons: app layer defines interface, infrastructure implements it, so dependencies point inward as should be in our architecture. It is now possible in handlers to coordinate work across different repositories in one transaction.

I read that it is questionable to do that. In DDD cross-aggregate communication is usually done via domain events:

• https://www.dandoescode.com/blog/ddd-modelling-aggregates-vs-entities#best-practices-for-choosing-an-aggregate-root
• https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation#implement-domain-events

On the other hand let's keep it simple now.

I also defined new conventions:

• change general naming convention on backend from lecturer to academic teacher (more generic, lecturers usually conduct only lectures)
• change ef core global naming convention for postgres db to snake_case (read here why)
• set global convention for controllers to return json with property keys in camelCase.
• set global naming convention for api endpoints - kebab-case

How to test (optional)

Nearly 1000 changed lines are just generated migrations.

useful for review:

• https://learn.microsoft.com/en-us/ef/core/modeling/constructors
• https://stackoverflow.com/questions/76662153/how-to-globally-configure-asp-net-core-6-api-routes-to-be-formatted-as-kebab-ca#76662588
• https://github.com/efcore/EFCore.NamingConventions
• https://antondevtips.com/blog/implementing-unit-of-work-pattern-in-ef-core
• https://www.dandoescode.com/blog/ddd-modelling-aggregates-vs-entities#best-practices-for-choosing-an-aggregate-root
• https://www.dandoescode.com/blog/domain-driven-design-patterns-for-aggregate-creation-mastery

To check whether api returns some data we need to add it. I generated seeder sql script with dummy data for that.

Steps to test:

1. run backend locally + db in docker (dev override with docker compose up database pgadmin). This should apply all new migrations. If you have errors drop all tables or db docker container with volume.
2. see new table, columns with pgadmin or your IDE built-in db tool. It will contain no data
3. run sql script (Infrastructure/Scripts/AcademicTeacherSeeder.sql) with some dummy academic teachers data.
4. run select sql query to get id and check what db has inside
5. use that id in scalar api docs to do request on new endpoint GET /api/academic-teachers/{id} (or use other api client)

Screenshots / recordings (for UI stuff)

...

Checklist

• PR is linked to an issue (tab on the right).
• Acceptance criteria (from issue) are met.
• All status checks (CI) are green.
• Tests added / updated.
• Docs updated (if applicable).

---

To have your PR reviewed put the link e.g. https://github.com/akai-org/put-wiki/pull/0 to the Review PR thread on put-wiki dc channel (you must be member of the AKAI discord server)