Coderise expert experience · GovTech / EduTech · Finland
Modernizing an early childhood education management platform in Finland
Three years as a Software Architect developing a domain-driven platform: from microservices and the data model to automated application matching, testing and production maintenance.
- 3 years
- working as a Software Architect on product development
- DDD
- domain-aligned microservice architecture and data model
- E2E
- testing complete scenarios and system integrations
Starting point
A working product required a new architectural direction.
The platform handled complex processes related to early education: from application acceptance and initial facility adjustment to decisions, fees, attendance and user accounts. The team took over a system previously developed by an external supplier, and the existing architecture and database model made further development difficult.
The Software Architect's task was to set the direction for modernization and coordinate technical decisions with the needs of the product. The work included both design and code development, code review, arrangements with Product Owners and support for backend and frontend teams.
Modernization
The domain has become a reference point for code and data.
Refactoring was not limited to organizing classes. It included the way of dividing responsibilities, the relational model and the rules of cooperation between modules.
- 01
Domain boundaries
Business processes were organized around clear boundaries of responsibility consistent with DDD.
- 02
Microservices
The solutions were designed so that the responsibilities of individual parts of the product remained clearly separated.
- 03
Data model
The structure of the PostgreSQL database was refactored towards a model that better reflects the domain.
- 04
Safe changes
Flyway migrations and tests limited the risk of introducing changes to the actively used system.
Domain automation
The system prepared recommendations, while the operator made the final decision.
One area under development was preplacement ? the initial matching of children with education providers. The mechanism analyzed application data and process criteria, then automatically matched and classified placement proposals.
The goal was not to replace people in the administrative process. The operator received structured information for review, reducing the time spent manually comparing applications and allowing them to focus on verification and the final decision.
- 01Applicationdata and process criteria
- 02Matchingpreplacement domain rules
- 03Classificationstructured proposals
- 04Operator's decisionverification and approval
Domain scope
The work included key stages of application and stay processing.
preplacementInitial fitting
Preparation and classification of facility proposals before actual placement.
placementPlacement in a facility
Handling the process of assigning a child to a selected educational institution.
decisionDecisions
Processes leading from application data to a formal decision by the operator.
decision paymentFee decisions
Domain logic related to the preparation and handling of charging decisions.
attendancePresence
Recording and processing information about the planned and actual stay.
accountsAccounts
Management of platform user accounts.
Quality and delivery
The architectural assumptions were verified in working scenarios.
Changes were secured with unit, integration and end-to-end tests created using JUnit 5 and Spock Framework. Maven and Flyway ensured repeatable builds and controlled database evolution.
Integration tests
Verification of cooperation between components and infrastructure.
E2E scenarios
Control of the full paths of the most important domain processes.
Google Cloud and CI/CD
Automatic delivery and monitoring of the production environment.
Product decisions
Agreeing on the direction of development with Product Owners and programmers.
The result of work
The modernization created a more stable basis for further development of the platform.
A clearer domain model
The architecture and data were focused on specific domain processes.
Less manual analysis
Automatic proposals supported operators when considering applications.
Greater change control
Tests, code reviews, migrations and monitoring reduced the risk of changes.
Technologies
Stack supporting system development and production maintenance.
- Java
- Spring Boot
- PostgreSQL
- Google Cloud
- Maven
- Flyway
- Spock Framework
- JUnit 5
- Integration testing
- End-to-end testing
- CI/CD
- Microservice architecture
- Domain-Driven Design
Next step
Are you developing a system that has outgrown its original architecture?
We can start with the domain, the constraints of the data model, and where changes are most risky today.