Project-Manager is a simple application for managing projects at company. You can create projects and teams. Projects can have features and status. Teams can have members and projects. You'll find more business requirments below.
We'll go from traditional layered architecture to hexagonal architecture A.K.A. Ports and Adapters architecture.
./gradlew bootRun - to run application.
./gradlew test - to run unit tests.
./gradlew clean build test- one to rule them all 💍
Start with endpoints. After that check tests. Whole domain is tested with unit tests. Isolated from controllers, database, framework. Tests are done with a use of repository implemented as HashMap. You also have AcceptanceTests that show user flow, bigger picture.
Idea is to see how does project changes while time passes. Each branch has some changes either refactor or new features implemented.
🏠 Architecture: Layered Architecure
-
POST: /teams- create a team. -
POST: /teams/:teamName/members- add members to the team. -
GET: /teams- show teams.
Needs and constraints:
- Team cannot be created if already exists
- How many projects team has?
🏠 Architecture: Layered Architecure
-
POST: /projects/drafts- create project draft (only project name). -
POST: /projects- create project with features. 📊 -
GET: /projects- show draft projects
Needs and constraints:
- JobPosition must be valid (Developer, Scrum Master...)
- Team can have no more than 3 projects at the time
🏠 Architecture: Hexagonal Architecure
Things done:
- Moving from layered (n-tier) architecture to Hexagonal Architecture (ports and adapters). 😎
- Introduced idea of shared-kernel from DDD
Improved tests:
- Unit tests without touching IO. Domain is tested with unit tests. Idea of
InMemoryRepositoryas HashMap. - Acceptance tests show flow of the app or bounded-context.
- Integration tests are only for most important business value paths because whole domain is tested with unit tests.
🏠 Architecture: Hexagonal Architecure
-
GET: /projects/:id- show project -
GET: /projects- show projects -
PUT: /projects/:id- change/update project -
PATCH: /projects/:id/started- start project when team assigned -
PATCH: /projects/:id/ended- close project when features are done
Needs and constraints:
- No
ifstatements! We can do better in Kotlin. Not something that you should avoid at any cost (its just a kata). - Project status and feature status ->
Statusmust be valid (TO_DO, IN_PROGRESS...) PriorityLevelfor project features must be valid (HIGH, MEDIUM, NOT_DEFINED...)
- Refactor introducing simple CQRS.
- monitoring, grafana, actuator, performance tests with gatling
branch: step-X-zoo-of-microservices
🏠 Architecture: Hexagonal Architecture (modularization on package level)
🕳 Tests: Integration/Acceptance/Unit
Backing-Services from Twelve-Factor-App methodology.
Services from our zoo:
🦓 user-autorization-service - authentication gateway that protects back-end resources. There is two kinds of resources protected and unprotected. First one requires user-level authentication and second one is just read-only such as listing of offers/products.
🐼 edge-service - gives possibility to expose unified REST API from all of ours backend services. To be able to do this, the Edge Service matches a request route’s URL fragment from a front-end application to a back-end microservice through a reverse proxy to retrieve the remote REST API response.
🐰 discovery-service - Edge-service matches a request route’s URL fragment from a front-end application to a back-end microservice through a reverse proxy to retrieve the remote REST API response.
🐿 centralized-configuration-server - Spring Cloud application that centralizes external configurations using various methodologies of building twelve-factor applications.
- Kotlin with spring
- Spock (groovy) for tests
- ArchUnit (kotlin) for architecture tests
- Gradle to build project
- PL: Prawie trywialna aplikacja do zarządzania projektami - bardziej szczegółowy opis projektu.
- ENG: The nature of domain driven design - about DDD strategic tools.