Joining the Backend Team
Understanding the Existing Engineering Context
আপনি একটি free preview lesson দেখছেন।
এখন পর্যন্ত আমরা আমাদের product requirement বুঝেছি, functional এবং non-functional requirements আলাদা করেছি, এবং user stories ও acceptance criteria তৈরি করেছি।
এই point-এ একটি beginner-level tutorial সাধারণত coding শুরু করে দেয়।
কিন্তু real engineering team-এ আরও একটি গুরুত্বপূর্ণ step থাকে:
আমরা যে system তৈরি করতে যাচ্ছি, সেটি কোন technical এবং organizational environment-এর মধ্যে থাকবে?
Software কোনো vacuum-এর মধ্যে তৈরি হয় না।
একটি নতুন backend service বানানোর সময়ও সাধারণত কিছু existing constraint, platform convention, dependency, deployment environment, security expectation এবং team practice থাকে।
একজন engineer যদি এগুলো না বুঝে implementation শুরু করে, তাহলে এমন solution তৈরি করতে পারে যা technically ভালো হলেও team বা production environment-এর সঙ্গে fit করে না।
এই lesson-এ আমরা আমাদের Order Management Backend-এর engineering context establish করব।
আমরা নতুন feature invent করব না।
বরং already agreed product scope বাস্তবে implement করার জন্য কোন environment-এর মধ্যে কাজ করছি সেটি পরিষ্কার করব।
You Rarely Start From Nothing
ধরে নিন আপনি একটি company-তে নতুন join করেছেন।
Product Manager বললেন:
We need a new Order Management Backend.
এর অর্থ সাধারণত এই নয়:
Choose any language.
Choose any database.
Invent your own API conventions.
Deploy wherever you want.
Use any authentication mechanism.
Create your own logging system.
Use any build tool.
বরং company-তে আগে থেকেই কিছু decision থাকতে পারে।
For example:
Backend language: Java
Framework: Spring Boot
Database platform: PostgreSQL
Source control: Git
CI: existing company pipeline
Deployment: containerized services
Authentication: company identity system
API style: REST/JSON
Observability: centralized logs and metrics
একজন engineer-এর প্রথম responsibility-এর একটি হলো এগুলো বুঝে নেওয়া।
Product Context vs Engineering Context
আমাদের product requirement বলেছে:
Customers should be able to place orders.
এটি product context।
Engineering context বলতে পারে:
The service must be implemented in Java.
The company uses PostgreSQL for transactional services.
Applications are packaged as containers.
Authentication is provided by an existing identity system.
Services expose REST APIs using JSON.
Notice করুন:
Product behaviour একই থাকতে পারে।
কিন্তু engineering context implementation choices constrain করতে পারে।
Constraints Are Not Always Bad
Constraint শব্দ শুনলে অনেক সময় negative মনে হয়।
কিন্তু সব constraint খারাপ নয়।
For example:
All backend services use Java.
এতে flexibility কমে।
কিন্তু benefit:
shared expertise
shared libraries
consistent tooling
easier support
easier hiring
common deployment practices
একইভাবে:
Use PostgreSQL.
এটি choice constrain করে।
কিন্তু যদি company already PostgreSQL operate করে, তাহলে নতুন database introduce না করাই sensible হতে পারে।
Good engineering মানে সবসময় unlimited choice নয়।
বরং:
Given the existing constraints, choose an appropriate solution.
Our Project Engineering Context
এই course-এর Order Management Backend-এর জন্য আমরা একটি clear engineering context establish করব।
এই context course-এর বাকি অংশে stable থাকবে unless later requirement explicitly change করে।
আমাদের context:
Language:
Java
Framework:
Spring Boot
Build Tool:
Gradle
API Style:
REST over HTTP using JSON
Primary Database:
PostgreSQL
Database Migrations:
Flyway
Source Control:
Git
Packaging:
Containerized application
Testing:
JUnit-based automated testing
External Dependency:
Payment provider HTTP API
Authentication:
An existing identity mechanism provides authenticated users
Deployment Model:
The application runs as a backend service in controlled environments
Observability:
The company has centralized logging and metrics infrastructure
এখন প্রতিটি point একটু বুঝি।
Java Is Already a Team Standard
এই project-এর implementation language:
Java
আমরা Java choose করার জন্য benchmark বা language comparison করব না।
কারণ course context অনুযায়ী learner Java foundation থেকে backend development-এ এসেছে।
Company context-এও Java একটি established backend language।
এটি আমাদের একটি important real-world lesson শেখায়:
নতুন project শুরু হলেই language selection discussion প্রয়োজন হয় না।
অনেক সময় organization-এর established stack-ই right default।
Spring Boot Is the Application Framework
আমাদের team Java backend services-এর জন্য:
Spring Boot
ব্যবহার করে।
এই course-এ Spring Boot শেখা হবে project-এর requirements fulfil করতে করতে।
আমরা Spring Boot-কে goal হিসেবে দেখব না।
Goal:
Build the Order Management Backend.
Spring Boot:
Tool used to build it.
এই distinction পুরো course-এ important থাকবে।
Why We Are Not Comparing Frameworks
এই stage-এ theoretically আমরা compare করতে পারতাম:
Spring Boot
Quarkus
Micronaut
Jakarta EE
কিন্তু আমাদের existing engineering context already Spring Boot establish করেছে।
তাই unnecessary framework comparison project এগিয়ে নিতে সাহায্য করবে না।
Real-world engineering-এ context অনেক decision eliminate করে দেয়।
এটি ভালো thing।
Decision fatigue কমে।
Gradle Is the Existing Build Tool
আমাদের project:
Gradle
ব্যবহার করবে।
Gradle-এর মাধ্যমে আমরা later:
compile
test
package
dependency management
build automation
করব।
এই course Gradle deep-dive course নয়।
যতটুকু backend engineer হিসেবে প্রয়োজন, project-এর মধ্যে ততটুকু শিখব।
REST and JSON Are the API Convention
Company-এর backend APIs conventionally HTTP-based REST APIs expose করে।
Data exchange format:
JSON
তাই product requirement:
Customer can create an order.
later একটি REST API operation হিসেবে expose হবে।
For example, eventually something like:
POST /orders
কিন্তু exact endpoint design আমরা API design module-এর আগে final করছি না।
এখন শুধু platform convention establish করছি:
HTTP + JSON + REST-style resources
PostgreSQL Is the Transactional Database
আমাদের Order Management Backend-এর primary persistent storage:
PostgreSQL
এই choice existing engineering platform-এর অংশ।
Order system-এর data naturally relational:
Customer
Product
Inventory
Order
Order Item
Payment
এগুলোর মধ্যে relationships আছে।
Order creation-এর সময় multiple related changes consistent রাখতে হবে।
PostgreSQL আমাদের transactional persistence-এর foundation হবে।
কিন্তু database schema আমরা এখনও design করছি না।
Database Choice and Database Design Are Different
Context:
We use PostgreSQL.
এটি already known।
কিন্তু এখনও open:
What tables do we need?
What relationships exist?
What constraints belong in the database?
What indexes are required?
What transaction boundaries are needed?
এগুলো later design decisions।
একটি technology choose করা মানে system design complete নয়।
Database Changes Must Be Versioned
Existing engineering practice অনুযায়ী database schema manually production-এ edit করা হবে না।
Schema changes migration-এর মাধ্যমে versioned হবে।
আমাদের tool:
Flyway
Later repository-তে আমরা migration files রাখব।
Conceptually:
V1__create_products.sql
V2__create_customers.sql
V3__create_orders.sql
Exact migration structure implementation-এর সময় নির্ধারণ করব।
মূল principle:
Application code-এর মতো database schema changes-ও controlled এবং reproducible হওয়া উচিত।
Authentication Is Not Our Identity Platform
আমাদের product requirement বলে customer এবং administrator আলাদা permissions পাবে।
কিন্তু এই course-এ আমরা নতুন identity provider বানাব না।
Engineering context অনুযায়ী:
An existing identity mechanism authenticates users.
আমাদের Order Management Backend-এর responsibility হবে:
receive authenticated identity
determine allowed operations
enforce resource ownership and permissions
অর্থাৎ:
Authentication source
↓
Order Management Backend
↓
Authorization
Spring Security module-এ আমরা এই boundary implement করব।
Why This Boundary Matters
ধরে নিন আমরা order service-এর মধ্যে নিজেরা password storage, password reset, email verification এবং account recovery বানানো শুরু করলাম।
এতে project scope dramatically বেড়ে যাবে।
কিন্তু product requirement ছিল:
Order Management Backend
না:
Identity Platform
Strong backend design-এর একটি core skill হলো system responsibility boundary maintain করা।
External Payment Provider Already Exists
আমাদের system নিজে card processing করবে না।
Product requirement already বলেছে payment একটি provider-এর মাধ্যমে হবে।
তাই system boundary:
Customer
↓
Order Management Backend
↓
Payment Provider
আমাদের responsibility:
initiate payment
handle provider response
track payment state
handle failures safely
prevent unintended duplicate processing
Provider-এর internal payment processing আমাদের responsibility নয়।
External Systems Are Unreliable by Definition
Payment provider external dependency।
যদিও provider highly reliable হতে পারে, network communication কখনও perfect guarantee দেয় না।
আমাদের consider করতে হবে:
timeout
connection failure
provider error
unexpected response
duplicate request
slow response
এই concern এখন identify করছি।
Implementation later integration module-এ করব।
Source Control Is Git
Team source code Git repository-তে manage করে।
এটি শুধু code backup mechanism নয়।
আমাদের engineering workflow later include করবে:
ticket
↓
branch/change
↓
commit
↓
pull request
↓
review
↓
merge
Course-এর repository history-ও ideally incremental development reflect করবে।
We Work Through Pull Requests
Main development workflow direct production branch modification নয়।
Change review-এর জন্য Pull Request ব্যবহার করা হবে।
এতে reviewer inspect করতে পারে:
implementation
tests
design impact
risk
documentation
আমাদের course-এ later PR descriptions এবং review process simulate করা হবে।
এই context এখন থেকেই important কারণ implementation approach small reviewable changes prefer করবে।
The Application Must Be Containerized
Deployment environment application container হিসেবে run করতে পারে।
তাই eventually আমাদের backend package হবে:
Java application
↓
Container image
↓
Runtime environment
এই stage-এ Dockerfile লিখছি না।
কিন্তু deployment context জানা architecture decisions-এর জন্য useful।
For example:
Application local filesystem-কে permanent storage হিসেবে treat করতে পারবে না।
Application Instances Should Be Replaceable
Containerized service environment-এ একটি useful assumption:
Application process বা instance disposable হতে পারে।
অর্থাৎ important business state local memory বা local disk-এর উপর permanently depend করা উচিত নয়।
Persistent state যাবে appropriate storage-এ:
PostgreSQL
এটি later scaling-এর জন্যও useful foundation।
Environments Exist
Real application সাধারণত শুধু:
localhost
এ run করে না।
আমাদের engineering context-এ multiple environment concept থাকবে।
Conceptually:
Local Development
↓
Test / CI
↓
Non-Production Environment
↓
Production
সব environment exact same infrastructure হবে না।
কিন্তু application configuration environment-aware হতে হবে।
Later আমরা Spring configuration এবং environment variables ব্যবহার করব।
Configuration Must Not Be Hardcoded
Bad:
String databasePassword = "super-secret-password";
বা:
String paymentUrl = "https://production-payment.example";
hardcoded everywhere।
Instead application configuration externalized হবে।
For example:
database connection
payment provider URL
credentials
environment-specific settings
configuration system থেকে আসবে।
Spring Boot module-এ আমরা এটি practically implement করব।
Secrets Are Not Application Code
Credentials, tokens এবং passwords source repository-তে commit করা যাবে না।
Engineering context:
Application code
≠
Secrets
Later আমরা secret management platform build করব না।
কিন্তু application এমনভাবে configure করব যাতে secrets runtime configuration থেকে নেওয়া যায়।
Centralized Logging Exists
Company applications-এর logs centralized infrastructure-এ collect করা হয়।
আমাদের service-এর responsibility:
useful logs produce করা
Central log platform build করা নয়।
Later আমরা structured logging এবং request correlation নিয়ে কাজ করব।
Important distinction:
Observability infrastructure
এবং:
Application instrumentation
এক জিনিস নয়।
Metrics Infrastructure Exists
একইভাবে company metrics collect করতে পারে।
আমাদের backend later expose করবে useful application metrics।
For example categories:
request behaviour
application health
important failures
Exact metrics later decide হবে।
আমরা এখন imaginary dashboard বা arbitrary metric invent করছি না।
Health Checks Are Expected
Deployment platform জানতে চাইবে application healthy কি না।
Spring Boot Actuator later health endpoint provide করতে সাহায্য করবে।
Again:
Product feature?
No.
কিন্তু:
Production engineering requirement?
Yes.
এই ধরনের requirement-এর কারণেই existing engineering context বোঝা জরুরি।
CI Is Part of the Delivery Process
Code merge করার আগে automated pipeline অন্তত:
build
test
করবে।
Later course-এ CI pipeline তৈরি করা হবে।
এখন important principle:
"Works on my machine" completion criterion নয়।
Change automated environment-এও build এবং test করতে হবে।
We Are Building One Application
আমাদের engineering context অনুযায়ী first version একটি single backend application।
Conceptually:
Order Management Backend
├── Customer capability
├── Product capability
├── Inventory capability
├── Order capability
└── Payment capability
আমরা এগুলোকে separate microservices করছি না।
এই decision current scope-এর সঙ্গে aligned।
A Single Application Does Not Mean No Structure
একটি monolithic application মানে:
all code in one giant package
নয়।
আমরা clear responsibility boundaries maintain করব।
For example conceptually:
customer
product
inventory
order
payment
কিন্তু exact package structure technical design module-এ discuss হবে।
এখন শুধু architecture boundary:
one deployable backend application
Why Not Microservices?
এই প্রশ্ন natural।
Commerce domain দেখেই কেউ ভাবতে পারে:
Product Service
Inventory Service
Order Service
Payment Service
Customer Service
কিন্তু আমাদের current requirements microservice complexity justify করেনি।
Multiple services introduce করলে নতুন problems আসে:
network communication
distributed failures
service discovery
deployment coordination
distributed transactions
observability complexity
data ownership complexity
এই complexity এখন প্রয়োজন নেই।
আমাদের goal:
Production-quality backend development foundation।
Distributed architecture later course-এর appropriate topic।
Technology Does Not Define Domain Boundaries
একটি subtle point:
আমরা one application ব্যবহার করছি মানে customer, order, payment সব একই concept নয়।
Logical boundaries still matter।
Example:
Order logic
payment provider HTTP details জানতে না পারলেও ভালো।
Similarly:
Product domain
controller-specific JSON logic-এর উপর depend করা উচিত নয়।
এই boundaries later domain modeling এবং architecture lessons-এ clearer হবে।
Understand Existing Conventions Before Creating New Ones
ধরে নিন company existing APIs এমন error format use করে:
{
"code": "RESOURCE_NOT_FOUND",
"message": "Resource was not found"
}
একজন new engineer যদি নিজের service-এ completely different format বানায়:
{
"oops": true,
"reason": "not there"
}
technically JSON valid।
কিন্তু platform consistency ভাঙে।
Real-world team-এ implementation-এর আগে existing conventions inspect করা উচিত।
আমাদের course project greenfield হলেও আমরা internally consistent conventions establish করব।
Existing Context Checklist
একজন engineer নতুন backend project-এ join করলে useful checklist হতে পারে:
Language and framework?
Build tool?
Repository conventions?
API conventions?
Authentication mechanism?
Authorization model?
Primary database?
Migration strategy?
Deployment environment?
Configuration management?
Secrets management?
Logging platform?
Metrics platform?
CI expectations?
Testing conventions?
Existing external dependencies?
Ownership boundaries?
সব project-এ সব question equally relevant নয়।
কিন্তু checklist context discovery improve করে।
Ownership Is Important
System-এর প্রতিটি অংশের responsibility clear হওয়া দরকার।
আমাদের current boundaries:
Order Management Backend Owns
Products required by this ordering domain
Inventory state
Orders
Order items
Order lifecycle
Payment state relevant to orders
External Identity Capability Owns
User authentication
Payment Provider Owns
Actual external payment processing
এখনও detailed database ownership বা service architecture define করছি না।
কিন্তু responsibility level-এ boundary clear।
"Payment State" vs "Payment Processing"
এই distinction useful।
আমাদের system জানতে পারে:
Order X payment succeeded.
এবং সেটা store করতে পারে।
কিন্তু card network-এর internal processing logic আমাদের system own করে না।
So:
Payment Provider
owns payment execution
Order Backend
owns order-related payment state
এই type boundary architecture clean রাখতে সাহায্য করে।
Understand Dependency Direction
Conceptually:
Order Management Backend
↓
PostgreSQL
Order Management Backend
↓
Payment Provider
Authenticated Identity
↓
Order Management Backend
এই arrows system relationships দেখায়।
Later architecture diagram আরও detail হবে।
এখন important হলো system isolated নয়।
Team Context Matters Too
Engineering context শুধু technology নয়।
Team workflow-ও relevant।
আমাদের simulated team practice:
Requirements are reviewed before implementation.
Significant design decisions are documented.
Work is broken into tickets.
Changes should be reviewable.
Automated tests are expected.
Pull Requests explain what changed.
Production readiness is part of delivery.
Incidents result in learning and corrective action.
Course-এর distinctive part এটাই।
আমরা শুধু final code দেখব না।
Decision process-ও follow করব।
Documentation Should Match Decision Size
Team documentation-heavy bureaucracy follow করে না।
Small change:
Ticket + PR
যথেষ্ট হতে পারে।
Important architecture decision:
ADR
দরকার হতে পারে।
Larger cross-cutting design:
RFC
appropriate হতে পারে।
Incident:
Incident Review
লিখতে হতে পারে।
সব change-এর জন্য একই documentation level দরকার নেই।
Existing Context Can Override Personal Preference
ধরে নিন আপনি personally Maven prefer করেন।
কিন্তু team-এর সব service Gradle use করে।
নতুন service-এর জন্য Gradle choose করা অনেক সময় better কারণ:
shared build tooling
shared CI
team familiarity
consistent maintenance
Engineering সবসময় personal favorite technology choose করার জায়গা নয়।
Challenge Constraints When Necessary
এর মানে existing decision কখনও question করা যাবে না—এমন নয়।
Suppose existing platform constraint actual requirement fulfil করতে পারে না।
তখন engineer evidence নিয়ে challenge করতে পারে।
Good discussion:
Current approach cannot satisfy requirement X because Y.
Option A keeps existing platform but has limitation Z.
Option B introduces new technology with these costs.
Recommendation: ...
কিন্তু:
I like technology X better.
সাধারণত sufficient reason নয়।
Greenfield Does Not Mean Constraint-Free
আমাদের Order Management Backend একটি new application।
কিন্তু greenfield হওয়া মানে:
no constraints
নয়।
আমরা existing company ecosystem-এর মধ্যে new service build করছি।
এটি real-world-এর common situation।
Questions We Can Now Answer
Previous lessons-এর কিছু engineering questions এখন answer করা যায়।
Which language?
Java
Which framework?
Spring Boot
Which primary database?
PostgreSQL
Which migration mechanism?
Flyway
API communication style?
REST over HTTP with JSON
Build tool?
Gradle
Deployment unit?
Containerized backend application
Does the order backend implement full identity management?
No.
Does it implement actual payment processing?
No. It integrates with an external payment provider.
Questions Still Open
Engineering context clear হলেও অনেক system design question এখনও open।
For example:
What are our domain entities exactly?
What should the package architecture look like?
What API resources should exist?
What is the order lifecycle?
What database schema should we use?
Where should transaction boundaries live?
How should errors be represented?
How should payment retries work?
Which metrics are meaningful?
এগুলো future modules-এর কাজ।
আমরা prematurely answer করব না।
Context Prevents Scope Creep
Without boundaries, payment requirement থেকে কেউ হয়তো শুরু করবে:
payment gateway
fraud detection
card storage
refund engine
settlement system
কিন্তু engineering context বলছে:
External payment provider handles payment processing.
তাই আমাদের scope narrow থাকে।
Similarly authentication:
Existing identity mechanism authenticates users.
তাই আমরা account platform বানাব না।
Boundary scope protect করে।
Context Also Prevents Overengineering
Suppose expected architecture context one deployable application।
তখন separate message broker introduce করে simple internal method call replace করা unnecessary হতে পারে।
Bad reasoning:
Kafka is scalable,
therefore we should use Kafka.
Better:
Do our current requirements require asynchronous
cross-system event delivery?
No.
Then do not add it.
Technology justification requirement থেকে আসা উচিত।
Our Initial System Context Diagram
এই stage-এ system conceptually এমন:
┌───────────────────────┐
│ Existing Identity │
│ Capability │
└───────────┬───────────┘
│
│ authenticated identity
▼
┌──────────────┐ ┌────────────────────────────┐
│ Client │────▶│ Order Management Backend │
└──────────────┘ HTTP│ │
│ Java + Spring Boot │
└──────────┬─────────┬───────┘
│ │
persist│ │ payment request
▼ ▼
┌────────────┐ ┌──────────────────┐
│ PostgreSQL │ │ Payment Provider │
└────────────┘ └──────────────────┘
এটি detailed architecture নয়।
এটি system context।
এই diagram-এর purpose:
What is inside our system?
What is outside?
What does our application depend on?
এই তিনটি question answer করা।
System Context Diagram vs Architecture Diagram
System context diagram high-level।
এখানে আমরা দেখাই:
our system
external actors
external dependencies
Detailed architecture later দেখাতে পারে:
controllers
services
domain
repositories
database
integration clients
দুটোকে mix না করাই ভালো।
Context Before Design
এখন আমাদের flow:
Product Requirement
↓
User Behaviour
↓
Acceptance Criteria
↓
Engineering Context
↓
Technical Design
এই sequence important।
কারণ design requirement এবং context দুটো satisfy করবে।
Example: Context Changes Design
Imagine same product requirement:
Customer can place an order.
Context A:
Single Java service
PostgreSQL
Moderate traffic
Context B:
Existing distributed order platform
multiple regions
event-driven inventory service
external pricing service
Business capability একই।
Technical solution completely different হতে পারে।
তাই architecture blog post দেখে context-free design copy করা dangerous।
Ask "What Already Exists?"
একজন নতুন engineer-এর powerful question:
What already exists that I should use rather than rebuild?
For our project:
Identity mechanism exists.
Payment provider exists.
Logging infrastructure exists.
Metrics infrastructure exists.
Deployment platform exists.
তাই আমরা integration করব।
Rebuild করব না।
Ask "What Does Our Service Own?"
আরেকটি powerful question:
What state and behaviour is this service responsible for?
আমাদের ক্ষেত্রে:
ordering domain
এই question unclear হলে services overlap করে, ownership confusing হয় এবং systems tightly coupled হয়ে যায়।
Ask "What Is a Hard Constraint?"
Not every convention hard constraint।
For example:
Java
PostgreSQL
deployment platform
আমাদের simulated environment-এ established constraints।
কিন্তু:
exact package names
exact controller structure
exact repository implementation
এখনও design choices।
Difference জানা দরকার।
Assumption Register
Real project-এ কিছু context completely confirmed না-ও হতে পারে।
Engineer assumptions লিখে রাখতে পারে।
Example:
ASSUMPTION-1
The external identity layer provides a stable user identifier.
ASSUMPTION-2
The payment provider exposes an HTTP API.
আমাদের course context-এ এগুলো given engineering context হিসেবে use করব।
কিন্তু real project-এ assumption verify করতে হতে পারে।
Dependency Risk
External dependency শুধু capability নয়; risk-ও।
Our major external dependency:
Payment Provider
Potential risk:
availability
latency
API changes
timeouts
duplicate processing
PostgreSQL-ও runtime dependency।
Identity system-ও dependency।
System design-এর সময় dependency failure consider করতে হবে।
We Do Not Need to Solve Dependency Failure Yet
এখনই retry policy লিখব না।
এখন শুধু identify করছি:
This operation crosses a system boundary.
এই awareness later design guide করবে।
Existing Context and Testing
Engineering environment আমাদের test strategy-তেও influence করবে।
For example:
Java
→ JUnit ecosystem
PostgreSQL
→ database integration tests matter
HTTP payment provider
→ integration boundary needs controlled testing
REST API
→ API behaviour needs integration testing
Testing module-এ আমরা এগুলো use করব।
Existing Context and Deployment
Containerized deployment মানে application start-up behaviour important।
For example:
Can application start with valid configuration?
Can health be checked?
Can it shut down safely?
Can migrations be applied safely?
এই concerns code writing-এর বাইরেও backend responsibility-এর অংশ।
Existing Context and Observability
Centralized logging থাকার অর্থ:
System.out.println(...)
randomly everywhere production strategy নয়।
Logs useful এবং machine-processable হওয়া উচিত।
Similarly metrics exist মানে:
measure everything
না।
Useful signals choose করতে হবে।
Later module-এ আমরা deliberate approach নেব।
Engineering Context Document
আমাদের repository-তে একটি lightweight document থাকতে পারে:
# Engineering Context
## Application
Order Management Backend
## Language
Java
## Framework
Spring Boot
## Build
Gradle
## API
REST / JSON over HTTP
## Persistence
PostgreSQL
## Database Migrations
Flyway
## Authentication
Provided by an existing identity capability.
## External Integrations
Payment provider over HTTP.
## Deployment
Containerized backend application.
## Delivery
Git, Pull Requests, automated CI.
## Observability
Application integrates with centralized logging
and metrics infrastructure.
এই document project context দ্রুত communicate করতে পারে।
Do Not Turn Context Into an RFC
এখনও আমরা technical proposal লিখছি না।
Engineering context mostly existing facts এবং constraints।
RFC later answer করবে:
Given this context and these requirements,
how should we design our system?
এই distinction important।
What an Engineer Should Do on Day One
ধরে নিন বাস্তবে আপনি নতুন team-এ join করেছেন।
Feature ticket pick করার আগে useful activities:
Read product context.
Run the existing service locally.
Understand repository structure.
Read recent relevant PRs.
Find architecture documentation.
Understand deployment flow.
Understand testing conventions.
Identify system dependencies.
Understand ownership boundaries.
Ask questions where documentation is unclear.
এই work "not coding" হলেও highly valuable।
Codebase Is Also Documentation
Existing system থাকলে code নিজেই context-এর source।
For example:
How are errors represented?
Existing controller code answer দিতে পারে।
How are migrations named?
Migration directory answer দিতে পারে।
How are tests structured?
Existing tests answer দিতে পারে।
Good engineer সবসময় নতুন pattern invent করার আগে existing pattern inspect করে।
But Existing Code Is Not Automatically Correct
আরেকটি important lesson:
Existing pattern আছে মানেই সেটি best practice নয়।
You may find:
duplicated logic
poor error handling
missing tests
outdated conventions
Blindly copy করা উচিত নয়।
Understand:
Is this intentional convention?
Legacy debt?
Temporary workaround?
Current recommended approach?
Context discovery judgement require করে।
Our Course Starts Greenfield, But Simulates Team Context
আমাদের actual learning repository নতুন হবে।
তাই inspect করার existing codebase থাকবে না।
এজন্য আমরা team context upfront establish করছি।
Course এগোনোর সঙ্গে সঙ্গে codebase নিজেই existing system হয়ে যাবে।
এটি important।
Module 14-এ যখন change request আসবে, learner আর greenfield developer থাকবে না।
তখন তাকে existing implementation understand করে safely modify করতে হবে।
The Context Will Become More Important Later
Initially:
small application
তাই context simple মনে হতে পারে।
কিন্তু later যখন production change আসবে:
existing database
existing API clients
existing tests
existing order history
existing production behaviour
তখন "just change the code" আর safe হবে না।
এই course learner-কে সেই evolution experience করাবে।
Engineering Principle
এই lesson-এর core principle:
A good technical solution is not just correct in isolation; it must fit the system, team, constraints, and operational environment around it.
আরেকভাবে:
Requirement
+
Engineering Context
=
Inputs to Design
শুধু requirement দিয়ে design incomplete।
শুধু technology context দিয়ে design করলে product need হারিয়ে যায়।
দুটোই প্রয়োজন।
Our Context Is Now Established
আমাদের Order Management Backend-এর starting context এখন clear:
Java
Spring Boot
Gradle
REST / JSON
PostgreSQL
Flyway
Git
Pull Requests
CI
Containerized deployment
Existing authentication capability
External payment provider
Centralized logging and metrics
আর architecture boundary:
One backend application
No microservices।
No Kafka।
No Redis।
No distributed architecture।
কারণ current requirements এগুলো demand করে না।
What We Have Not Added
Notice করুন আমরা product scope-এ নতুন capability যোগ করিনি।
আমরা add করিনি:
shipping
discounts
refunds
multiple warehouses
notifications
recommendations
event streaming
Engineering context product scope expand করে না।
এটি implementation environment define করে।
Where We Are in Module 1
আমাদের journey এখন:
Product Requirement
↓
Requirement Analysis
↓
Functional vs Non-Functional Requirements
↓
User Stories and Acceptance Criteria
↓
Engineering Context
↓
Definition of Done
↓
Initial Engineering Backlog
পরের দুটি lesson-এর পরে আমাদের project implementation planning-এর জন্য প্রস্তুত হবে।
Summary
এই lesson-এ আমরা শিখেছি:
- Software কোনো isolated environment-এর মধ্যে তৈরি হয় না।
- Product requirement এবং engineering context আলাদা।
- Existing technology এবং platform constraints design choices influence করে।
- Constraint সবসময় negative নয়; consistency এবং operational simplicity valuable।
- New project হলেই প্রতিটি technology নতুন করে choose করতে হয় না।
- Order Management Backend Java, Spring Boot, Gradle, PostgreSQL এবং REST/JSON ব্যবহার করবে।
- Database changes Flyway migration-এর মাধ্যমে versioned হবে।
- Authentication existing identity capability থেকে আসবে; আমরা identity platform বানাব না।
- Actual payment processing external payment provider-এর responsibility।
- আমাদের backend order-related payment state own করবে।
- Application containerized environment-এ run করবে।
- Source control, Pull Requests, automated testing এবং CI engineering workflow-এর অংশ।
- Central logging এবং metrics infrastructure existing platform capability; application useful instrumentation provide করবে।
- First version একটি single deployable backend application হবে।
- Microservices বা distributed infrastructure current scope-এ justify করা হয়নি।
- System boundaries এবং external dependencies implementation-এর আগে clear করা গুরুত্বপূর্ণ।
- Good solution শুধু technically valid হলেই যথেষ্ট নয়; existing engineering environment-এর সঙ্গে fit করতে হবে।
পরের lesson হবে Definition of Done।
সেখানে আমরা define করব একটি engineering task কখন সত্যিই complete বলা যাবে—শুধু code লেখা শেষ হলে নয়, বরং implementation, testing, review, documentation এবং delivery quality-এর দিক থেকেও।