Welcome to the Engineering Team

এই course-এ আমরা Java বা Spring Boot-এর বিভিন্ন feature আলাদা আলাদা example দিয়ে শিখব না।

আমরা একটি real-world backend application তৈরি করব, এবং পুরো course জুড়ে সেই application-টিকেই ধাপে ধাপে evolve করব।

আপনি এখানে শুধু একজন learner নন।

এই মুহূর্ত থেকে ধরে নিন, আপনি একটি software engineering team-এর নতুন backend engineer।

আপনার team একটি নতুন Order Management Backend তৈরি করতে যাচ্ছে।

এই system ব্যবহার করে customer product দেখতে পারবে, order তৈরি করতে পারবে, payment করতে পারবে এবং নিজের order history দেখতে পারবে। অন্যদিকে administrative users product এবং inventory manage করতে পারবে।

কিন্তু আমরা সরাসরি code লেখা শুরু করব না।

কারণ professional software development সাধারণত এভাবে শুরু হয় না:

New Project
    ↓
Open IDE
    ↓
Start Coding

বরং process-টি অনেকটা এমন:

Business Problem
      ↓
Requirements
      ↓
Technical Discussion
      ↓
Design
      ↓
Engineering Tasks
      ↓
Implementation
      ↓
Testing
      ↓
Review
      ↓
Deployment
      ↓
Operation

এই course-এর মূল উদ্দেশ্য হলো এই পুরো process-টি আপনাকে practically experience করানো।

---

The Project We Are Joining

ধরে নিন আমরা একটি commerce company-তে কাজ করছি।

Company ইতোমধ্যে বিভিন্ন product বিক্রি করে। এখন তারা তাদের ordering process-এর জন্য একটি নতুন backend system তৈরি করতে চায়।

আমাদের team-এর দায়িত্ব হবে সেই backend তৈরি করা।

Initial version-এ system-টি কয়েকটি core capability support করবে:

• customer management
• product management
• inventory management
• order creation
• payment processing
• order history
• order cancellation
• administrative operations

Course এগিয়ে যাওয়ার সঙ্গে সঙ্গে আমরা এই capability-গুলো implement করব।

কিন্তু একটি গুরুত্বপূর্ণ বিষয় মনে রাখতে হবে:

আমরা শুরুতেই পুরো system build করব না।

Professional software development-এ বড় system সাধারণত ছোট ছোট deliverable change-এর মাধ্যমে তৈরি হয়।

আমাদের project-ও একইভাবে evolve করবে।

---

Your Role

এই project-এ আপনি একজন Backend Engineer।

এর অর্থ শুধু API লেখা নয়।

একজন backend engineer-এর কাজের মধ্যে থাকতে পারে:

• requirement বোঝা
• ambiguous requirement নিয়ে প্রশ্ন করা
• technical solution design করা
• API contract define করা
• database model design করা
• business logic implement করা
• tests লেখা
• অন্য engineer-এর code review করা
• নিজের change explain করা
• production failure investigate করা
• existing system modify করা
• technical decision document করা

Course-এর প্রতিটি stage-এ আমরা এই responsibilities-এর কিছু অংশ practise করব।

---

Software Development Is More Than Writing Code

Programming শেখার সময় আমরা প্রায়ই একটি simplified model দেখি:

Problem
   ↓
Code
   ↓
Output

Small programming exercise-এর জন্য এটি ঠিক আছে।

কিন্তু production software-এর ক্ষেত্রে problem এবং code-এর মাঝখানে আরও অনেক কিছু থাকে।

ধরা যাক Product Manager বললেন:

A customer should be able to place an order.

শুনতে খুব simple requirement।

কিন্তু backend engineer হিসেবে আমাদের সঙ্গে সঙ্গে অনেক প্রশ্ন আসা উচিত।

For example:

Can an order contain multiple products?

Can the same product appear more than once?

What happens if inventory is insufficient?

When should inventory decrease?

Can a customer cancel an order?

Can an unpaid order be cancelled?

Can a paid order be cancelled?

What happens if payment succeeds but our database update fails?

How do we calculate the final price?

Should the price come from the current product price?

What happens if the product price changes later?

এখানেই software engineering এবং শুধু coding-এর মধ্যে বড় পার্থক্য তৈরি হয়।

Code লেখা অনেক সময় solution-এর সবচেয়ে straightforward অংশ।

কঠিন অংশ হলো:

ঠিক কোন problem solve করতে হবে এবং system কীভাবে behave করবে—সেটি পরিষ্কারভাবে বোঝা।

---

We Will Not Start with Spring Boot

এটি একটি Java backend development course।

তবুও প্রথম কয়েকটি lesson-এ Spring Boot code খুব কম থাকবে বা একেবারেই থাকবে না।

এটি intentional।

কারণ framework একটি tool।

Spring Boot আপনাকে controller, dependency injection, configuration, database integration এবং আরও অনেক capability দেয়।

কিন্তু Spring Boot আপনাকে বলে না:

• requirement ঠিকভাবে বোঝা হয়েছে কি না
• কোন responsibility কোন component-এর হওয়া উচিত
• API ভালোভাবে design করা হয়েছে কি না
• business invariant কী
• transaction কোথায় প্রয়োজন
• failure হলে কী হবে
• কোন change risky
• production incident কীভাবে investigate করতে হবে

Framework শেখা প্রয়োজন।

কিন্তু framework জানা এবং backend engineer হওয়া একই বিষয় নয়।

এই course-এ আমরা দুটোই একসঙ্গে build করব:

Backend Engineering Thinking
            +
Java / Spring Boot Implementation

---

Our Engineering Workflow

পুরো course জুড়ে আমরা একটি repeatable workflow follow করব।

একটি feature সাধারণত এই flow দিয়ে যাবে:

Requirement
    ↓
Understand the Problem
    ↓
Clarify Ambiguity
    ↓
Technical Design
    ↓
RFC / ADR when needed
    ↓
Break Work into Tickets
    ↓
Implementation
    ↓
Testing
    ↓
Pull Request
    ↓
Code Review
    ↓
Merge
    ↓
Deploy
    ↓
Observe

প্রতিটি ছোট change-এর জন্য অবশ্যই full RFC প্রয়োজন হয় না।

এটিও একটি গুরুত্বপূর্ণ engineering lesson।

Documentation-এর উদ্দেশ্য bureaucracy তৈরি করা নয়।

Documentation-এর উদ্দেশ্য হলো প্রয়োজনীয় জায়গায় thinking এবং communication improve করা।

আমরা পরে শিখব কখন একটি short ticket যথেষ্ট, কখন ADR দরকার, এবং কখন larger RFC প্রয়োজন।

---

What Is an RFC?

Course-এ আপনি বারবার RFC শব্দটি দেখবেন।

RFC সাধারণত Request for Comments বোঝায়।

Software team-এ এটি এমন একটি document হতে পারে যেখানে engineer একটি technical problem এবং proposed solution explain করে যাতে implementation-এর আগে অন্যরা সেটি review করতে পারে।

একটি RFC-তে থাকতে পারে:

Problem

Context

Goals

Non-Goals

Proposed Design

Alternatives

Risks

Rollout Plan

সব company একই format ব্যবহার করে না।

কোথাও RFC বলা হয়, কোথাও design document, technical proposal বা engineering proposal বলা হয়।

নামের চেয়ে গুরুত্বপূর্ণ হলো purpose:

বড় technical decision code-এ লুকিয়ে ফেলার আগে সেটি নিয়ে structured ভাবে চিন্তা এবং আলোচনা করা।

আমরা আমাদের Order Management Backend-এর জন্যও RFC লিখব।

---

What Is an ADR?

আরেকটি term আমরা ব্যবহার করব:

ADR — Architecture Decision Record

ADR সাধারণত একটি specific technical decision record করে।

For example:

Why are we using PostgreSQL?

Why are we using database migrations?

Why did we choose a particular API error format?

RFC সাধারণত একটি larger proposal explain করতে পারে।

ADR একটি particular decision এবং তার reasoning preserve করতে সাহায্য করে।

Months পরে নতুন engineer project-এ join করলে সে শুধু code দেখে সিদ্ধান্তের কারণ অনুমান না করে ADR পড়ে context বুঝতে পারে।

---

Engineering Tickets

Design করার পর আমরা কাজকে ছোট ছোট engineering task-এ ভাগ করব।

For example:

BACKEND-101 Bootstrap Order Management Service

BACKEND-102 Create Product domain model

BACKEND-103 Add Product persistence

BACKEND-104 Expose Product API

BACKEND-105 Implement Order creation

একটি ভালো ticket engineer-কে শুধু:

"Build orders"

বলবে না।

বরং প্রয়োজনীয় context এবং expected behaviour বোঝাবে।

আমরা পরে user story, acceptance criteria এবং Definition of Done নিয়ে বিস্তারিত কাজ করব।

---

Why Tickets Matter

Ticket শুধু project manager-এর tracking tool নয়।

ভালোভাবে লেখা ticket engineering work-এর boundary তৈরি করে।

ধরা যাক ticket:

Implement ordering system

এটি এত বড় যে engineer জানেই না কোথা থেকে শুরু করবে।

এর পরিবর্তে:

BACKEND-121

Create an order for an existing customer.

Acceptance Criteria:

- Order must contain at least one item.
- Every referenced product must exist.
- Requested quantity must be available.
- Order total must be calculated from product prices.
- Invalid requests must return an appropriate API error.

এখন problem অনেক clearer।

Engineering work ছোট হওয়া মানে শুধু management সহজ হওয়া নয়।

এতে:

• review সহজ হয়
• testing সহজ হয়
• risk কমে
• rollback সহজ হয়
• progress বোঝা যায়
• parallel work করা সহজ হয়

---

Pull Requests Are Communication

Code লেখা শেষ হওয়ার পর আমাদের কাজ শেষ নয়।

Professional team-এ change সাধারণত review-এর মধ্য দিয়ে যায়।

আপনি একটি Pull Request, বা সংক্ষেপে PR, তৈরি করতে পারেন।

একটি useful PR description এমন হতে পারে:

## What

Adds order cancellation support.

## Why

Customers need to cancel unpaid orders.

## Changes

- Added cancellation domain logic
- Restores reserved inventory
- Added cancellation API
- Added integration tests

## Testing

- Unit tests
- API integration tests

## Risks

Inventory restoration happens inside the order transaction.

এখানে PR শুধু code container নয়।

এটি reviewer-এর সঙ্গে communication।

Reviewer যেন দ্রুত বুঝতে পারে:

• কী change হয়েছে
• কেন হয়েছে
• কীভাবে test করা হয়েছে
• কোথায় risk আছে

এই skill বাস্তব engineering career-এ অত্যন্ত গুরুত্বপূর্ণ।

---

Production Changes Everything

Local machine-এ application run হওয়া software development-এর শেষ নয়।

Production system-এর ক্ষেত্রে আরও প্রশ্ন আসে:

How will we know if the service is healthy?

What happens when the database is unavailable?

What happens if an external payment API times out?

How do we find a failed request?

What happens during deployment?

Can the database migration break existing instances?

Can the same payment request be processed twice?

What happens if two customers try to buy the final item simultaneously?

এই ধরনের প্রশ্নই backend engineering-কে interesting করে।

আমরা course-এর শুরুতে সব answer জানব না।

জানার প্রয়োজনও নেই।

System evolve হওয়ার সঙ্গে সঙ্গে problems naturally সামনে আসবে।

তারপর আমরা appropriate solution শিখব।

---

We Will Make Mistakes

Course project-টিকে intentionally perfect system হিসেবে শুরু করা হবে না।

বাস্তব software-ও perfect architecture দিয়ে শুরু হয় না।

আমরা কিছু decision নেব।

পরে নতুন requirement আসবে।

কিছু assumption ভুল প্রমাণিত হতে পারে।

কিছু design পরিবর্তন করতে হবে।

একটি production incident-ও simulate করা হবে।

এটা failure নয়।

এটাই software development।

Real systems সময়ের সঙ্গে evolve করে।

একজন strong engineer-এর skill শুধু প্রথমবার সঠিক code লেখা নয়।

বরং:

existing system safely change করার ক্ষমতা।

---

Our First Version Will Be a Modular Application

আমাদের Order Management Backend প্রথমে একটি single backend application হিসেবে তৈরি হবে।

Conceptually:

Order Management Backend

├── Customers
├── Products
├── Inventory
├── Orders
└── Payments

Course-এর এই stage-এ আমরা system-টিকে unnecessary microservices-এ ভাগ করব না।

কারণ আমাদের বর্তমান goal হলো production-quality backend development শেখা।

Microservices, Kafka, distributed transactions, distributed caching এবং similar topics-এর জন্য প্রথমে একটি solid backend foundation প্রয়োজন।

Architecture complexity নিজে কোনো achievement নয়।

একটি system যত simple রেখে requirement satisfy করা যায়, সাধারণত সেটিই ভালো starting point।

---

What We Will Build Toward

Course শেষে আমাদের application শুধু কয়েকটি CRUD endpoint-এর collection হবে না।

আমরা এমন একটি backend তৈরি করব যেখানে থাকবে:

HTTP APIs

Business Logic

Domain Models

Validation

PostgreSQL Persistence

Database Migrations

Transactions

Authentication

Authorization

External Service Integration

Testing

Logging

Metrics

Health Checks

Docker

CI

Deployment Practices

কিন্তু এগুলো checklist হিসেবে শেখা হবে না।

প্রতিটি capability project-এর প্রয়োজন থেকে আসবে।

For example:

আমরা PostgreSQL শিখব কারণ আমাদের data persist করতে হবে।

Transactions শিখব কারণ order creation-এর একাধিক database operation atomic হতে হবে।

Authentication শিখব কারণ customer-এর order অন্য customer দেখতে পারবে না।

Timeout এবং retry শিখব কারণ payment provider সবসময় perfectly respond করবে না।

Observability শিখব কারণ production failure হলে আমাদের জানতে হবে system-এর ভেতরে কী ঘটছে।

এই distinction গুরুত্বপূর্ণ:

Technology first নয়, problem first.

---

Your Engineering Repository

Course এগিয়ে গেলে আমাদের repository roughly এমন হতে পারে:

order-management/
├── src/
│   ├── main/
│   └── test/
│
├── docs/
│   ├── rfcs/
│   ├── adr/
│   └── incidents/
│
├── Dockerfile
├── compose.yaml
└── README.md

src/-এ থাকবে application code।

docs/rfcs/-এ থাকবে larger technical proposals।

docs/adr/-এ থাকবে architecture decisions।

docs/incidents/-এ পরে production incident reviews থাকবে।

এর মাধ্যমে আমরা code-এর পাশাপাশি engineering context-ও repository-এর অংশ হিসেবে রাখব।

---

A Backend Engineer Thinks in Behaviour

এই course-এ একটি habit তৈরি করার চেষ্টা করব।

Feature দেখেই implementation নিয়ে ভাবা শুরু করবেন না।

প্রথমে behaviour নিয়ে ভাবুন।

ধরা যাক requirement:

Customer can cancel an order.

Immediately এই code লিখতে যাবেন না:

order.setStatus(OrderStatus.CANCELLED);

প্রথমে প্রশ্ন করুন:

Which orders can be cancelled?

Can a paid order be cancelled?

Should inventory be restored?

Can the same order be cancelled twice?

Who is allowed to cancel the order?

What response should the API return?

Do we need to notify another system?

তারপর implementation।

এই order গুরুত্বপূর্ণ:

Behaviour
    ↓
Design
    ↓
Code

না যে:

Code
    ↓
Try to figure out behaviour later

---

Think Like You Just Joined the Team

এই মুহূর্তে আমাদের কাছে এখনও complete requirement নেই।

আমরা শুধু high-level context জানি:

Company একটি Order Management Backend তৈরি করতে চায়।

একজন inexperienced developer হয়তো এখানেই IDE খুলে OrderController লিখতে শুরু করবে।

কিন্তু আমরা তা করব না।

আমাদের next responsibility হলো business requirement বুঝে নেওয়া।

আমরা জানতে চাই:

• কে system ব্যবহার করবে
• তারা কী করতে পারবে
• কোন behaviour mandatory
• কোন behaviour এই version-এর বাইরে
• কোন constraints আছে
• success কীভাবে define করা হবে

এই information ছাড়া implementation শুরু করলে খুব সম্ভব আমরা দ্রুত code লিখব, কিন্তু ভুল system তৈরি করব।

---

Engineering Principle

এই lesson থেকে একটি principle মনে রাখুন:

The job is not to write code. The job is to solve the right problem with software.

Code সেই কাজের একটি গুরুত্বপূর্ণ অংশ।

কিন্তু code-এর আগে আসে understanding।

আর production-এর পরে আসে ownership।

একজন backend engineer পুরো lifecycle-এর অংশ।

---

What Comes Next

পরের lesson-এ আমরা আমাদের team-এর actual product requirement হাতে পাব।

সেটি initially intentionally high-level থাকবে।

তারপর আমরা requirement পড়ব একজন engineer-এর মতো এবং আলাদা করব:

What is explicitly required?

What are we assuming?

What is ambiguous?

What needs clarification?

What should not be built yet?

সেখান থেকেই আমাদের Order Management Backend-এর real engineering journey শুরু হবে।