Kursus · MitmekeelneKesktaseÕppeteekonna Backend Engineering 2. etapp

Backend Engineering with Java & Spring Boot

Build Production-Ready Backend Systems with Java, Spring Boot, PostgreSQL, and Modern Engineering Practices

14 moodulit
159 õppetundi
16 nädalat
Mitmekeelne

Fumu igas õppetunnisKüsi Fumult mis tahes õppetunnis. Ta selgitab materjali selle õppetunni põhjal, kus sa parasjagu oled.
Kinnitatud tunnistus sinu profiililVarstiLisatakse sinu avalikule profiilile lõpetamise päeval ja seotakse sinu kinnitatud identiteediga.

Kursuse ülevaade

Kursusest

It’s time to move from the foundations of Java and Object-Oriented Programming into real-world backend development.

In this course, you won’t just learn Spring Boot features or annotations. You will build a production-style backend application from the ground up, step by step, and learn professional backend development through the process.

The course follows the workflow of a real engineering team—from understanding requirements and creating technical designs, RFCs, and engineering tickets to implementation, testing, code review, deployment, and investigating production issues.

Throughout the course, the same application will continue to evolve. Instead of learning each new concept through isolated examples, you will see where it fits in a real system, why it is needed, and how it is applied in practice.

The goal of this course is not simply to complete a backend project.

The goal is to build the foundation you need as a backend engineer to think about, design, build, and maintain production-quality software.

Õppekava

14 moodulit · 159 õppetundi · 31 tasuta eelvaadet

1Joining the Backend Team10 õppetundi3 eelvaadetBefore any code exists, this module does the work a new backend engineer does in the first weeks on a team. You read the Product Manager's brief for the Order Management Backend and separate what it says from what you are tempted to assume, sort its requirements into functional behaviour and non-functional qualities, and turn the capabilities into User Stories with testable Acceptance Criteria. Then you learn the engineering context the system must fit, agree a Definition of Done, and break the work into the `BACKEND-101` to `BACKEND-128` backlog that the rest of the course implements, ordered by dependency, value and risk. The exercises produce the team's real working documents in your own `docs/` folder: a requirement review, Stories, a context document, a DoD review and a backlog plan.

1.1 Welcome to the Engineering TeamVideo ja lugemine · 21 minEelvaade
1.2 Understanding the Product RequirementVideo ja lugemine · 25 minEelvaade
1.3 Functional vs Non-Functional RequirementsVideo ja lugemine · 24 minEelvaade
1.4 User Stories and Acceptance CriteriaLugemine
1.5 Understanding the Existing Engineering ContextLugemine
1.6 Definition of DoneLugemine
1.7 Creating Our Initial Engineering BacklogLugemine
1.8 Prioritizing and Refining the BacklogLugemine
Selles moodulis on veel 2 õppetundi

2Designing the System8 õppetundi2 eelvaadetBefore the first line of code, the team turns the agreed requirements into a design it can review. This module finds the domain concepts and decides which have identity: Product, a separate Inventory, Order with its OrderItems and purchase-time prices, and a `CustomerId` from the identity capability instead of a local Customer. It assigns each responsibility to handlers, use cases, domain objects, repositories or the `PaymentService` boundary, and shapes them into a modular monolith with one package per capability. The design is then written down as RFC-001, its durable decisions are recorded as ADR-001 to ADR-005, and a review sharpens vague requirements, rejects speculative infrastructure and decides what is ready to build. Every exercise produces a design document that you keep in your project's `docs/` folder.

2.1 From Requirements to Technical DesignLugemine · 17 minEelvaade
2.2 Identifying Domain EntitiesLugemine · 19 minEelvaade
2.3 Defining System ResponsibilitiesLugemine
2.4 Designing the Initial ArchitectureLugemine
2.5 Writing Our First RFCVideo ja lugemine · 11 min
2.6 Architecture Decision RecordsLugemine
2.7 Reviewing and Revising a Technical DesignLugemine
2.8 Module 2 Practice Solutions: Lessons 2.01–2.07Lugemine

3Building the Spring Boot Application10 õppetundi3 eelvaadetThe design is approved; this module starts the code. You create the `order-management` repository with Spring Initializr and complete the first ticket, `BACKEND-101`: a Gradle build that works from a clean checkout, a Spring Boot entry point and a context test. Then the module explains what the framework does with it: how project structure decides what Spring finds, how Dependency Injection and the Application Context build the object graph, and why startup fails when a Bean is missing, ambiguous or part of a cycle. It sets the rules for configuration, profiles and secrets, the package convention every later ticket follows, and the local workflow with PostgreSQL in Docker Compose. At the end, the project builds, its test passes without a database, and it starts with the `local` profile.

3.1 Creating a Spring Boot ApplicationLugemine · 16 minEelvaade
3.2 Understanding Spring Boot Project StructureLugemine · 12 minEelvaade
3.3 Dependency InjectionLugemine · 14 minEelvaade
3.4 Beans and the Application ContextLugemine
3.5 Configuration and Application PropertiesLugemine
3.6 Environment-Specific ConfigurationLugemine
3.7 Structuring a Backend CodebaseLugemine
3.8 Running the Application LocallyLugemine
Selles moodulis on veel 2 õppetundi

4Domain Modeling10 õppetundi2 eelvaadetThe application starts, but it holds no business code yet; this module writes its core. Product, Inventory, Order, OrderItem and the typed IDs become plain Java classes that protect their own rules: a price is never negative, stock never drops below zero, an Order has at least one line, keeps its purchase-time prices, derives its total with exact arithmetic and moves only from `UNPAID` to `PAID` or `CANCELLED`. Along the way the module separates entities, value objects and DTOs, keeps HTTP, security and persistence out of the domain, decides what Customer means when another system owns identity, and finds the line between a passive data holder and an object that does too much. Every rule is tested with plain JUnit, without Spring or a database.