Course · MultilingualIntermediateStage 2 of Backend Engineering

Backend Engineering with Java & Spring Boot

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

Offered byTarkev
  • 14 modules
  • 159 lessons
  • 16 weeks
  • Multilingual
  • Fumu in every lessonAsk Fumu inside any lesson. It explains the material using the lesson you are on.
  • A verified certificate on your recordSoonAdded to your public profile the day you finish, tied to your verified identity.
Course overview

About this course

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.

Curriculum

14 modules · 159 lessons · 31 free previews
1Joining the Backend Team10 lessons3 previewsBefore 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.1 Welcome to the Engineering TeamVideo and reading · 21 minPreview
  2. 1.2 Understanding the Product RequirementVideo and reading · 25 minPreview
  3. 1.3 Functional vs Non-Functional RequirementsVideo and reading · 24 minPreview
  4. 1.4 User Stories and Acceptance CriteriaReading
  5. 1.5 Understanding the Existing Engineering ContextReading
  6. 1.6 Definition of DoneReading
  7. 1.7 Creating Our Initial Engineering BacklogReading
  8. 1.8 Prioritizing and Refining the BacklogReading
  9. 2 more lessons in this module
2Designing the System8 lessons2 previewsBefore 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.
  1. 2.1 From Requirements to Technical DesignReading · 17 minPreview
  2. 2.2 Identifying Domain EntitiesReading · 19 minPreview
  3. 2.3 Defining System ResponsibilitiesReading
  4. 2.4 Designing the Initial ArchitectureReading
  5. 2.5 Writing Our First RFCVideo and reading · 11 min
  6. 2.6 Architecture Decision RecordsReading
  7. 2.7 Reviewing and Revising a Technical DesignReading
  8. 2.8 Module 2 Practice Solutions: Lessons 2.01–2.07Reading
3Building the Spring Boot Application10 lessons3 previewsThe 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.
  1. 3.1 Creating a Spring Boot ApplicationReading · 16 minPreview
  2. 3.2 Understanding Spring Boot Project StructureReading · 12 minPreview
  3. 3.3 Dependency InjectionReading · 14 minPreview
  4. 3.4 Beans and the Application ContextReading
  5. 3.5 Configuration and Application PropertiesReading
  6. 3.6 Environment-Specific ConfigurationReading
  7. 3.7 Structuring a Backend CodebaseReading
  8. 3.8 Running the Application LocallyReading
  9. 2 more lessons in this module
4Domain Modeling10 lessons2 previewsThe 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.
  1. 4.1 Turning Business Concepts into Domain ModelsReading · 13 minPreview
  2. 4.2 Entities, Value Objects, and DTOsReading · 18 minPreview
  3. 4.3 Separating Domain Logic from Transport LogicReading
  4. 4.4 Modeling ProductReading
  5. 4.5 Modeling CustomerReading
  6. 4.6 Modeling Orders and Order ItemsReading
  7. 4.7 Modeling Order StateReading
  8. 4.8 Avoiding Anemic Domain ModelsReading
  9. 2 more lessons in this module
10 more modules · 121 lessons
After this course

The last course on the Backend Engineering roadmap

This course is in stage 2 of 2: Build APIs.

See the whole roadmap