Joining the Backend Team
Creating Our Initial Engineering Backlog
আপনি একটি free preview lesson দেখছেন।
এখন পর্যন্ত আমরা অনেক গুরুত্বপূর্ণ কাজ করেছি, কিন্তু এখনও production code লেখা শুরু করিনি।
আমরা:
- product requirement বুঝেছি
- ambiguity identify করেছি
- functional এবং non-functional requirements আলাদা করেছি
- user stories এবং acceptance criteria লিখেছি
- engineering context establish করেছি
- Definition of Done ঠিক করেছি
এখন আমাদের next responsibility:
বড় product requirement-কে এমন engineering work-এ ভাঙা, যা একজন engineer বাস্তবে pick করে implement করতে পারে।
এই lesson-এ আমরা আমাদের Order Management Backend-এর প্রথম engineering backlog তৈরি করব।
এটি শুধু task list হবে না।
আমরা বুঝব:
- কোন কাজ আগে হওয়া উচিত
- কোন কাজ অন্য কাজের উপর depend করে
- একটি ticket কত বড় হওয়া উচিত
- product story এবং engineering ticket-এর পার্থক্য কী
- foundational work এবং feature work কীভাবে balance করতে হয়
- unnecessary scope কীভাবে backlog-এ ঢোকা থেকে prevent করতে হয়
এই lesson শেষে আমাদের হাতে একটি realistic initial backlog থাকবে।
এরপর আমরা technical design-এর দিকে যেতে পারব।
What Is a Backlog?
Backlog হলো planned work-এর ordered collection।
একটি software team-এর backlog-এ থাকতে পারে:
features
bugs
technical work
documentation
operational work
investigations
আমাদের current project নতুন।
তাই initial backlog-এর বড় অংশ হবে:
foundation
+
first product capabilities
কিন্তু backlog মানে শুধু:
things we could build someday
নয়।
Useful backlog এমন work represent করে যা:
- understood enough
- scoped enough
- prioritized enough
- actionable enough
যাতে engineer বাস্তবে কাজ শুরু করতে পারে।
Product Backlog vs Engineering Backlog
আমাদের product-level stories আছে:
Browse Available Products
Create an Order
View Order History
Cancel an Eligible Order
Pay for an Order
Manage Products
Manage Inventory
এগুলো user value describe করে।
কিন্তু engineering implementation-এর জন্য এগুলো এখনও broad।
For example:
Create an Order
এর মধ্যে থাকতে পারে:
domain model
persistence
inventory checks
price calculation
transaction handling
API
validation
tests
তাই আমরা product story-কে engineering work-এ break করব।
A Ticket Should Represent a Coherent Change
একটি ticket ideally এমন কাজ represent করে যা:
understandable
bounded
reviewable
testable
Bad ticket:
BACKEND-100
Build backend.
এটি project-level goal।
Engineer কোথা থেকে শুরু করবে clear নয়।
আরেকটি bad example:
BACKEND-101
Implement orders, payments, authentication,
inventory, tests and deployment.
এটি অনেক বেশি scope।
এমন ticket:
- review করা কঠিন
- estimate করা কঠিন
- parallelize করা কঠিন
- failure হলে isolate করা কঠিন
- progress বোঝা কঠিন
But Tickets Can Be Too Small
অন্য extreme-ও bad।
For example:
BACKEND-201
Create Product.java file.
BACKEND-202
Add name field.
BACKEND-203
Add price field.
BACKEND-204
Add getter.
এই level-এর fragmentation useful নয়।
এতে process overhead actual engineering work-এর চেয়ে বেশি হয়ে যায়।
Ticket ideally meaningful engineering outcome represent করবে।
A Good Ticket Has a Clear Outcome
Compare:
Bad:
Add JPA.
Better:
Persist products in PostgreSQL.
Bad:
Create controller.
Better:
Expose an API for administrators to create products.
Bad:
Add tests.
Better:
Add integration coverage for product creation and validation.
Technology action-এর চেয়ে outcome-focused wording usually clearer।
Ticket Structure
আমাদের course project-এর tickets-এর জন্য lightweight format ব্যবহার করব।
# BACKEND-XXX — Ticket Title
## Context
Why does this work exist?
## Scope
What should be implemented?
## Acceptance Criteria
What behaviour must be true?
## Out of Scope
What should not be added as part of this ticket?
## Dependencies
What must exist before this work can be completed?
সব ticket-এর জন্য every section mandatory নয়।
কিন্তু complex work-এর ক্ষেত্রে structure useful।
Ticket IDs
আমরা examples-এ ticket ID ব্যবহার করব:
BACKEND-101
BACKEND-102
BACKEND-103
এগুলো কোনো specific project-management tool require করে না।
বাস্তবে team Jira, Linear, GitHub Issues বা অন্য tool ব্যবহার করতে পারে।
আমাদের জন্য ID-এর purpose:
clear reference
For example:
This PR implements BACKEND-104.
Start With Dependencies, Not Just Features
Product priority alone implementation order determine করে না।
Suppose highest-priority feature:
Create an Order
কিন্তু order create করতে আমাদের দরকার:
application
products
inventory
customers
database
তাহলে order ticket প্রথম implementation task হতে পারে না।
আমাদের dependency chain বুঝতে হবে।
Conceptually:
Application Foundation
↓
Persistence Foundation
↓
Product
↓
Inventory
↓
Customer
↓
Order
↓
Payment
এটি strict one-by-one execution order নয়।
কিছু work parallel হতে পারে।
কিন্তু dependencies backlog ordering influence করে।
First, We Need a Running Application
আমাদের first technical milestone:
একটি clean Spring Boot application repository যা locally build এবং run করতে পারে।
এই কারণে প্রথম ticket:
BACKEND-101
Bootstrap Order Management Backend
এটি business feature নয়।
কিন্তু সব future feature-এর foundation।
BACKEND-101 — Bootstrap Order Management Backend
Context
আমাদের backend implementation-এর জন্য initial Spring Boot application প্রয়োজন।
Scope
Create the Gradle project.
Configure Spring Boot.
Establish the initial application entry point.
Add baseline project configuration.
Verify the application can build and start locally.
Acceptance Criteria
The project builds successfully with Gradle.
The Spring Boot application starts successfully.
The repository contains the agreed baseline project structure.
A clean checkout can be built without IDE-specific setup.
Out of Scope
Product APIs
Database schema
Authentication
Order logic
Payment integration
Docker production setup
Notice করুন আমরা bootstrap ticket-এর মধ্যে half the course ঢুকিয়ে দিচ্ছি না।
Why "Create All Packages" Is Not Yet a Ticket
আমরা চাইলে BACKEND-101-এর মধ্যে:
customer
product
inventory
order
payment
সব package upfront create করতে পারতাম।
কিন্তু empty structure speculative হতে পারে।
Better হলো feature আসার সঙ্গে relevant structure emerge করা।
আমরা architecture plan করব, কিন্তু dozens of empty classes create করব না শুধু future-looking structure দেখানোর জন্য।
Database Foundation
Product, inventory, customer এবং order persist করতে PostgreSQL দরকার।
তাই early backlog-এ database integration foundation দরকার।
BACKEND-102
Configure PostgreSQL and Flyway
BACKEND-102 — Configure PostgreSQL and Flyway
Context
Application-এর transactional data PostgreSQL-এ persist হবে এবং schema changes Flyway migrations-এর মাধ্যমে versioned হবে।
Scope
Configure PostgreSQL connectivity.
Add required persistence dependencies.
Configure Flyway.
Verify migrations run when the application starts in the expected environment.
Provide a local development database setup.
Acceptance Criteria
The application can connect to PostgreSQL.
Flyway is enabled.
A migration can be applied successfully.
Local development can start the required database consistently.
Automated tests are not dependent on a manually configured developer database.
Out of Scope
Product schema
Order schema
Inventory schema
Production database provisioning
Notice করুন schema-specific work আলাদা থাকবে।
Should Docker Compose Be Added Here?
Local PostgreSQL চালানোর জন্য Docker Compose useful হতে পারে।
আমাদের engineering context containerized tooling allow করে।
তাই BACKEND-102-এর local development scope-এর মধ্যে PostgreSQL setup থাকতে পারে।
কিন্তু production Dockerfile এই ticket-এর scope নয়।
Why?
কারণ local dependency setup এবং production application packaging আলাদা concerns।
Product Capability Comes Before Orders
Order item product reference করবে।
তাই product domain first meaningful business capability।
Product management story-এর initial implementation break করতে পারি:
BACKEND-103
Define Product domain model
BACKEND-104
Persist products
BACKEND-105
Create product administration API
BACKEND-106
Expose available product browsing
কিন্তু এখানে careful হতে হবে।
Define Product domain model alone কি meaningful ticket?
Depends on scope।
আমরা যদি শুধু একটি class create করি, ticket খুব small।
কিন্তু product rules model করা এবং tests দিয়ে behaviour establish করা meaningful change হতে পারে।
BACKEND-103 — Model the Product Domain
Context
Orders এবং inventory-এর আগে system-এর product concept define করতে হবে।
Scope
Initial product model must represent the product information required by the current stories.
Product must support active/inactive ordering state.
Acceptance Criteria
A product has a stable identity.
A product has the information required by the agreed v1 ordering flow.
The model represents whether the product is available for ordering.
Invalid product state is prevented where relevant.
Domain behaviour has focused tests where behaviour exists.
Out of Scope
Inventory quantity
Discounts
Categories
Images
Product variants
Physical deletion
Notice করুন আমরা unrequested commerce features যোগ করছি না।
BACKEND-104 — Persist Products
Context
Product data application restart-এর পরও থাকতে হবে।
Scope
Create the required product database migration.
Map the product persistence model.
Provide repository access needed by current use cases.
Acceptance Criteria
Products can be stored in PostgreSQL.
Products can be retrieved by identifier.
Product active/inactive state is persisted.
Schema creation is managed through Flyway.
Persistence behaviour is covered by integration tests.
Dependencies
BACKEND-102
BACKEND-103
BACKEND-105 — Create Product Administration API
Product story বলেছে administrator product manage করতে পারবে।
Initial slice-এ আমরা product creation দিয়ে শুরু করতে পারি।
Context
Administrators need to add products to the catalog.
Scope
Expose product creation through the REST API.
Validate the supported input.
Persist the created product.
Return the created product representation.
Acceptance Criteria
An administrator can create a valid product.
Invalid required input is rejected.
The created product is persisted.
Regular customers cannot perform the administrative operation
once authorization is integrated.
শেষ criterion নিয়ে subtle issue আছে।
Authentication এখনও implement হয়নি।
তাহলে এই ticket কি authorization-এর উপর block হবে?
আমাদের two options:
- security foundation আগে implement করা
- business endpoint first তৈরি করা এবং authorization ticket later apply করা
কিন্তু acceptance criterion originally administrator-only।
Security ছাড়া feature technically incomplete।
তাই backlog dependency properly plan করা দরকার।
Authentication Becomes a Planning Dependency
আমাদের product stories-এ customer এবং administrator permissions already defined।
তাই administrative APIs implement করার আগে minimum authentication/authorization foundation প্রয়োজন হতে পারে।
However, course plan অনুযায়ী dedicated security module later আছে।
আমরা foundational product implementation-এর সময় securityকে fake করব না।
Instead initial development sequence-এ endpoints তৈরি করতে পারি, কিন্তু story-level completion security module পর্যন্ত fully complete হবে না—এটি confusing।
Better approach:
Early modules domain এবং API mechanics teach করবে, কিন্তু production authorization completion security module-এ হবে।
তবে backlog-এ আমরা dependency explicitly track করব।
আমরা feature ticket এবং later security-hardening ticket আলাদা রাখতে পারি, কিন্তু requirement যেন হারিয়ে না যায়।
Backlog Can Contain Future Work
Initial backlog মানে সব ticket এখনই implement করতে হবে না।
আমরা complete v1 engineering backlog তৈরি করতে পারি এবং priority/order অনুযায়ী later modules-এ pick করতে পারি।
তাই security-related tickets backlog-এ থাকবে, কিন্তু early implementation stage-এ না-ও আসতে পারে।
Product Browsing
Product browsing customer-facing first useful vertical slice।
BACKEND-106
Expose available product browsing
Context
Customers need to view products before creating an order।
Scope
Expose a read API for products available for ordering.
Support bounded results.
Return the product data required by the ordering flow.
Acceptance Criteria
Only products available for ordering are returned.
Product price is included.
The endpoint supports paginated or otherwise bounded retrieval.
Inactive products are not returned as orderable products.
Dependencies
BACKEND-104
Inventory Should Be Separate From Product
Product এবং inventory related, but same responsibility নয়।
Conceptually:
Product
identity
descriptive data
price
ordering status
Inventory
available quantity
এই separation later useful হবে কারণ inventory changes product metadata changes-এর মতো নয়।
আমাদের tickets:
BACKEND-107
Model and persist inventory
BACKEND-108
Implement inventory administration
BACKEND-107 — Model and Persist Inventory
Context
Order creation available quantity-এর উপর depend করবে।
Scope
Represent inventory for an orderable product.
Persist inventory quantity.
Prevent invalid negative persisted quantity.
Acceptance Criteria
Each relevant product has inventory state.
Inventory quantity can be stored and retrieved.
Inventory quantity cannot be validly set below zero.
Inventory persistence is managed through Flyway migrations.
Persistence behaviour is integration-tested.
Out of Scope
Multiple warehouses
Backorders
Inventory reservations across services
Inventory audit history
BACKEND-108 — Implement Inventory Administration
Context
Administrators need to keep available stock accurate।
Scope
Expose the required API to view current inventory.
Allow supported inventory adjustment.
Validate resulting quantity.
Acceptance Criteria
An administrator can view current inventory.
An administrator can perform the agreed inventory adjustment.
Inventory cannot become negative through the administrative operation.
Unauthorized users will be prevented once security enforcement is implemented.
Again, security dependency will be handled explicitly later।
Customer Domain
Orders must belong to a customer।
We need a local representation of customer identity relevant to ordering।
Important boundary:
আমরা identity platform বানাচ্ছি না।
Customer ticket account/password implement করবে না।
BACKEND-109 — Model Customer Identity for Ordering
Context
Every order must belong to a customer, while authentication itself is provided externally।
Scope
Represent the customer information needed by the Order Management Backend.
Acceptance Criteria
The backend can represent a customer with a stable identifier.
Order-related data can reference that customer.
The model does not introduce password management or identity-provider responsibilities.
Out of Scope
Passwords
Registration
Password reset
Email verification
Identity provider implementation
Do We Need a Customer Creation API?
Initial product brief customer management mention করেছে high-level project capabilities-এর মধ্যে, but explicit v1 stories focus on authenticated customers using ordering features.
Since existing identity capability owns authentication, আমরা arbitrary customer registration API invent করব না।
Backend-এর local customer representation কীভাবে populate হবে later design clarify করবে।
এখানে important scope discipline:
"Customer exists" requirement থেকে full customer-account platform বানানো যাবে না।
Order Domain Comes Next
এখন product, inventory এবং customer concepts available।
আমরা order-এর core behaviour model করতে পারি।
Order-related backlog:
BACKEND-110
Model Order and Order Item domain
BACKEND-111
Persist orders and order items
BACKEND-112
Implement order creation workflow
BACKEND-113
Expose order creation API
BACKEND-114
Expose customer order history
BACKEND-115
Implement order cancellation
BACKEND-110 — Model Order and Order Item Domain
Context
Order creation, history, payment এবং cancellation সব order lifecycle-এর উপর depend করবে।
Scope
Model:
Order
Order Item
Order status required by current v1 behaviour
Historical item pricing
Acceptance Criteria
An order belongs to a customer.
An order contains at least one order item.
An order item represents product, quantity, and purchase-time price.
The order total can be derived or maintained consistently from its items.
The model supports the states required by current ordering,
payment, and cancellation behaviour.
Invalid state transitions are not silently allowed.
Out of Scope
Shipping state
Refund lifecycle
Fulfilment workflow
Return management
Do Not Invent Too Many Order States
A common modeling mistake:
CREATED
PENDING
PROCESSING
CONFIRMED
PACKED
READY
SHIPPED
DELIVERED
RETURNED
REFUNDED
PARTIALLY_REFUNDED
Sounds realistic for commerce।
But our v1 requirement does not need this full fulfilment lifecycle।
We should model only states required by:
unpaid
paid
cancelled
Exact enum/design technical design stage-এ final হবে।
BACKEND-111 — Persist Orders and Order Items
Context
Orders must remain available for history, payment এবং cancellation।
Scope
Create order-related migrations.
Persist orders.
Persist order items.
Preserve purchase-time pricing.
Acceptance Criteria
An order can be stored with its customer relationship.
Order items are persisted with quantity and historical price information.
Persisted orders can be retrieved with the data required by current use cases.
Database constraints support required data integrity where appropriate.
Integration tests verify persistence behaviour.
Dependencies
BACKEND-109
BACKEND-110
BACKEND-112 — Implement Order Creation Workflow
এটি project-এর first major business workflow।
Context
Customers need to create valid orders without violating product or inventory rules।
Scope
The workflow must:
validate requested items
verify products exist
verify products are orderable
validate quantities
check inventory
determine prices from backend data
calculate total
update inventory according to the agreed model
persist the complete order
Acceptance Criteria
Use the already agreed order-creation criteria:
An order contains at least one item.
Every product exists.
A product appears at most once per request.
Quantity is a positive whole number.
Only orderable products may be included.
Requested quantity does not exceed available inventory.
The backend determines prices.
The backend calculates the order total.
Purchase-time prices are preserved.
Any invalid item causes the whole request to fail.
The resulting order belongs to the requesting customer.
The operation does not leave partial state on failure.
This ticket is bigger than previous tickets, but coherent:
one complete business workflow।
Why Order Creation Is Not Split Into Ten Tiny Tickets
We could create:
validate quantity
validate product
calculate total
decrease inventory
save order
as separate tickets।
But these pieces independently provide little value and are tightly coupled within one workflow।
Better:
- domain/persistence foundation separate
- business workflow cohesive
- API exposure separate
This creates reasonable review boundaries।
BACKEND-113 — Expose Order Creation API
Context
The implemented order workflow must be available to clients through REST।
Scope
Define order creation request model.
Validate transport-level input.
Invoke the order creation workflow.
Return the created order representation.
Map expected business failures to the project API error contract.
Acceptance Criteria
A valid request creates an order through the existing workflow.
Invalid request shapes are rejected.
Known business validation failures produce consistent API errors.
Client-provided pricing is not trusted as order pricing.
The API contract is documented.
Dependencies
BACKEND-112
Why Workflow and Controller Are Separate Tickets
Because they represent different responsibilities।
Workflow ticket verifies business behaviour independently of HTTP।
API ticket handles:
HTTP
JSON
request/response
error mapping
This makes design and testing clearer।
BACKEND-114 — Expose Customer Order History
Context
Customers need to review previous orders।
Scope
Retrieve orders belonging to the requesting customer.
Provide bounded/paginated results.
Return historical order-item information.
Acceptance Criteria
Only the requesting customer's orders are returned.
Historical item prices remain unchanged when product prices change.
Multiple orders can be retrieved without requiring the full history in one response.
The API contract is documented.
Authorization enforcement later depends on security foundation।
BACKEND-115 — Implement Order Cancellation
Context
Customers may cancel eligible unpaid orders।
Scope
Validate order ownership.
Validate cancellation eligibility.
Cancel the order.
Restore inventory reserved by the order.
Preserve transactional consistency.
Acceptance Criteria
A customer can cancel their own unpaid order.
A customer cannot cancel another customer's order.
A paid order cannot be cancelled in v1.
An already-cancelled order cannot be cancelled again.
Successful cancellation restores the relevant inventory.
Failure does not leave order and inventory in inconsistent states.
Payment Work
Payment is an external integration and deserves its own sequence।
BACKEND-116
Define payment integration contract
BACKEND-117
Implement payment provider client
BACKEND-118
Implement order payment workflow
BACKEND-119
Expose order payment API
Why Start With an Integration Contract?
We should avoid placing HTTP provider details directly into order logic।
First define what our application needs from a payment capability।
Conceptually:
PaymentService / PaymentGateway
pay(order...)
↓
success / failure
Exact interface later design module-এ আসবে।
Ticket purpose is boundary clarity, not unnecessary abstraction।
BACKEND-116 — Define Payment Integration Boundary
Context
Order logic needs payment capability without owning the provider's HTTP implementation details।
Scope
Define the application-facing payment contract required by v1।
Acceptance Criteria
The application can represent a payment attempt outcome.
The boundary contains only capabilities needed by current order payment flow.
Provider-specific HTTP details do not leak into order domain logic.
The design accounts for successful and failed payment outcomes.
Out of Scope
Refunds
Multiple payment providers
Stored cards
Payment webhooks unless required by the agreed provider flow
BACKEND-117 — Implement Payment Provider Client
Context
The payment integration boundary must communicate with the configured external payment provider।
Scope
Call the provider over HTTP.
Configure provider endpoint and credentials externally.
Handle supported success and failure responses.
Apply timeout behaviour.
Keep provider-specific mapping within the integration layer.
Acceptance Criteria
The configured provider can be called through the integration boundary.
Successful responses are translated into the application's payment result.
Provider failures do not appear as successful payments.
Timeouts are handled explicitly.
Provider configuration is not hardcoded.
Retry and idempotency details will be treated carefully in the external-services module rather than guessed here।
BACKEND-118 — Implement Order Payment Workflow
Context
A customer needs to pay an eligible order।
Scope
Validate ownership.
Validate payment eligibility.
Initiate payment through the payment boundary.
Update order-related payment state on confirmed success.
Do not mark the order paid on failed payment.
Prevent unintended duplicate successful application.
Acceptance Criteria
A customer may pay only for their own eligible order.
A cancelled order cannot be paid.
An already-paid order is not processed as a new successful payment.
A confirmed payment marks the order paid.
A failed payment does not mark the order paid.
Duplicate successful application is prevented according to the final integration design.
BACKEND-119 — Expose Order Payment API
Scope
Expose the payment workflow over the REST API।
Acceptance Criteria
A valid payment request invokes the existing payment workflow.
Known payment failures are represented through the API contract.
The payment endpoint does not expose provider-specific internals unnecessarily.
The API is documented.
Security Work
Our stories require authenticated customer and administrator behaviour।
Initial security backlog:
BACKEND-120
Integrate authenticated user identity
BACKEND-121
Enforce customer resource ownership
BACKEND-122
Enforce administrator permissions
BACKEND-120 — Integrate Authenticated User Identity
Context
Existing identity capability authenticates users; our backend needs access to the authenticated identity।
Scope
Configure Spring Security integration required by the backend.
Expose authenticated user information to application logic.
Reject protected requests without valid authentication.
Out of Scope
User registration
Password storage
Password reset
Building an identity provider
BACKEND-121 — Enforce Customer Resource Ownership
Context
Customers must not access or mutate another customer's orders।
Acceptance Criteria
A customer can access their own order resources.
A customer cannot view another customer's order.
A customer cannot cancel another customer's order.
A customer cannot pay for another customer's order.
Ownership rules are covered by integration tests.
BACKEND-122 — Enforce Administrator Permissions
Context
Product and inventory administration must be restricted।
Acceptance Criteria
Authorized administrators can perform supported administrative operations.
Regular customers cannot create or modify products through administrative APIs.
Regular customers cannot modify inventory.
Authorization behaviour is integration-tested.
Production-Readiness Work
Later modules introduce observability and deployment।
Those belong in the backlog too।
For now high-level tickets can include:
BACKEND-123
Add structured application logging
BACKEND-124
Add request correlation
BACKEND-125
Expose application health checks
BACKEND-126
Add application metrics
BACKEND-127
Containerize the application
BACKEND-128
Create CI build and test pipeline
We will refine these when their module begins।
Backlog items do not all need full detail months before implementation।
Testing Is Not a Final Ticket
A common bad backlog:
Build all features
then
BACKEND-999
Add tests
We will not do this।
Testing belongs inside each feature's Definition of Done।
For example:
BACKEND-112
Implement order creation workflow
already requires relevant tests।
Dedicated testing module later teaches strategy and improves coverage where needed, but automated testing starts with implementation।
Documentation Is Also Not One Final Cleanup Ticket
Similarly:
Build everything
then document later
is dangerous।
Relevant documentation should evolve with the change।
Examples:
API ticket
→ API documentation
architecture decision
→ ADR
larger design
→ RFC
Later documentation module can improve patterns, but context should not be postponed until everyone forgets why decisions were made।
Technical Design Must Happen Before Many of These Tickets
We now have a backlog, but are we ready to implement every ticket?
No।
For example:
BACKEND-112
Implement order creation workflow
requires design decisions around:
domain model
transaction boundary
inventory behaviour
Before implementation, Module 2 will create the necessary technical design and RFC।
This is realistic।
Backlog can exist before every implementation detail is finalized।
Ticket Status Does Not Mean Ready to Start
We may have:
BACKEND-118
Implement order payment workflow
in backlog।
But it may currently be:
Blocked / Not Ready
because payment integration design is not complete।
Backlog is planning inventory।
Ready work is a subset of it।
Dependencies
Let's express the key dependencies conceptually।
BACKEND-101 Bootstrap
↓
BACKEND-102 PostgreSQL + Flyway
↓
BACKEND-103 Product Domain
↓
BACKEND-104 Product Persistence
↓
BACKEND-106 Product Browsing
Inventory:
BACKEND-102
↓
BACKEND-107 Inventory Persistence
↓
BACKEND-108 Inventory Administration
Orders:
Product + Inventory + Customer
↓
BACKEND-110 Order Domain
↓
BACKEND-111 Order Persistence
↓
BACKEND-112 Order Creation Workflow
↓
BACKEND-113 Order API
Cancellation:
BACKEND-112
↓
BACKEND-115 Cancellation
Payment:
Order Domain
+
Payment Boundary
↓
Payment Client
↓
Payment Workflow
↓
Payment API
Security then applies across protected operations।
Not Every Dependency Is a Hard Code Dependency
For example:
BACKEND-106 Product Browsing
technically authentication ছাড়া public endpoint হতে পারে।
Product brief says customers browse products, but it did not say browsing must be authenticated।
So we should not invent that restriction।
Admin operations, order ownership, payment, cancellation clearly require permission enforcement।
This is why dependency planning must follow actual requirements rather than a blanket rule।
Prioritizing the Backlog
We want early progress that reduces uncertainty and produces usable vertical slices।
A practical first implementation order after design could be:
1. Bootstrap application
2. Database and migration foundation
3. Product domain and persistence
4. Product administration foundation
5. Product browsing
6. Inventory domain and persistence
7. Inventory administration
8. Customer identity representation
9. Order domain
10. Order persistence
11. Order creation workflow
12. Order creation API
13. Order history
14. Cancellation
15. Authentication and authorization enforcement
16. Payment integration
17. Production-readiness work
18. Shipping
Exact ordering may shift slightly as later technical design reveals dependencies।
That is normal।
Why Payment Is Not First
Payment sounds like a major feature।
But payment requires an order।
Order requires products এবং inventory।
So building payment first would either:
force mocks and temporary structures everywhere
or:
create abstractions without real domain context
Better to build stable prerequisites first।
Why Observability Is Not Left Until Production
Although production-readiness module comes later, basic logging will naturally exist earlier।
Dedicated observability work later will make it deliberate and structured।
We won't pretend production concerns suddenly appear only at the final module।
But we also won't interrupt every early lesson with advanced operational design before the core application exists।
Vertical Slice Example
Suppose after foundation we choose product creation।
A vertical slice might include:
HTTP request
↓
Controller
↓
Application logic
↓
Domain
↓
Repository
↓
PostgreSQL
plus:
tests
migration
API documentation
After merge, one small capability genuinely works end-to-end।
This is more valuable than separately completing:
all controllers
then:
all repositories
with nothing actually usable।
Horizontal Foundation vs Vertical Feature
Some work is naturally horizontal:
Spring Boot bootstrap
database configuration
security framework setup
error contract
Feature work is often better vertical।
A healthy project uses both।
Bad extreme 1:
Build six months of infrastructure before first feature.
Bad extreme 2:
Duplicate every shared concern inside each feature.
Our backlog aims for minimal foundation followed by meaningful vertical work।
A Ticket Should Be Reviewable
Suppose PR has:
4,000 changed lines
database schema
auth
orders
payments
Docker
CI
Reviewer has huge cognitive load।
Even if code is good, review quality drops।
Smaller tickets encourage smaller PRs।
For example:
BACKEND-104
Persist products
could produce a focused PR containing:
migration
persistence mapping
repository
integration tests
Reviewer understands one coherent change।
But Don't Optimize for Tiny PRs at the Cost of Cohesion
A PR with:
one field renamed
can be good when that is actual task।
But splitting one cohesive feature into ten dependent PRs can create more temporary states and review overhead।
Goal:
smallest change that still makes engineering sense.
Not:
smallest possible diff.
Ticket Scope and Pull Request Scope
Ideally one ticket often maps to one primary PR।
But not a strict law।
A large ticket may need multiple PRs।
A small related set of tickets may sometimes share a PR if team agrees।
Our course examples will generally keep:
one bounded ticket
≈
one focused PR
because it teaches traceability well।
Tickets Should Carry the "Why"
Weak ticket:
Add unitPrice to OrderItem.
Better:
Preserve purchase-time pricing for order items.
Context:
Historical orders must not change when product prices change.
Now engineer understands why unitPrice matters।
Later refactor can preserve intent even if implementation changes।
Avoid Solution-First Tickets Too Early
Suppose backlog item:
Use pessimistic locking for inventory.
Why?
We haven't completed transaction/concurrency design yet।
Better backlog:
Ensure concurrent order creation cannot violate inventory constraints.
Then technical design can decide mechanism।
Implementation-specific ticket can be created after decision is made।
This prevents backlog from silently becoming architecture।
Spikes and Investigations
Sometimes we cannot write an implementation ticket yet because unknown technical information exists।
Real teams may create a spike or investigation ticket।
Example:
Investigate payment provider idempotency support.
Output could be:
supported API behaviour
limitations
recommended integration approach
But our current course plan already has a dedicated external integration module where provider behaviour will be defined।
We should only create investigation work when there is a real unknown।
Not every task needs a spike।
Avoid Inventing Unknowns Just to Simulate Process
A bad course could create fake complexity:
We don't know if PostgreSQL supports transactions.
Let's create a research ticket.
That would be artificial।
We know our engineering context and should use established knowledge।
Real-world simulation should feel authentic, not bureaucratic theatre।
Bugs Are Backlog Items Too
Later production incident may generate tickets such as:
BUG-201
Prevent duplicate order creation under identified retry scenario
or corrective work:
BACKEND-240
Add metric for failed payment reconciliation
Backlog evolves with system reality।
It is never truly "finished."
Product Change Creates Backlog Change
Module 14 will introduce a production change request।
At that point we won't rebuild planning from scratch।
We will:
understand new requirement
↓
assess impact
↓
update design if needed
↓
add or modify backlog items
Existing backlog/history gives context।
That is how long-lived systems evolve।
Initial Backlog by Epic
We can now organize our work into larger groups।
Epic 1 — Application Foundation
BACKEND-101
Bootstrap Order Management Backend
BACKEND-102
Configure PostgreSQL and Flyway
Epic 2 — Product Management
BACKEND-103
Model the Product Domain
BACKEND-104
Persist Products
BACKEND-105
Create Product Administration API
BACKEND-106
Expose Available Product Browsing
Epic 3 — Inventory Management
BACKEND-107
Model and Persist Inventory
BACKEND-108
Implement Inventory Administration
Epic 4 — Customer Context
BACKEND-109
Model Customer Identity for Ordering
Epic 5 — Ordering
BACKEND-110
Model Order and Order Item Domain
BACKEND-111
Persist Orders and Order Items
BACKEND-112
Implement Order Creation Workflow
BACKEND-113
Expose Order Creation API
BACKEND-114
Expose Customer Order History
BACKEND-115
Implement Order Cancellation
Epic 6 — Payment
BACKEND-116
Define Payment Integration Boundary
BACKEND-117
Implement Payment Provider Client
BACKEND-118
Implement Order Payment Workflow
BACKEND-119
Expose Order Payment API
Epic 7 — Security
BACKEND-120
Integrate Authenticated User Identity
BACKEND-121
Enforce Customer Resource Ownership
BACKEND-122
Enforce Administrator Permissions
Epic 8 — Production Readiness
BACKEND-123
Add Structured Application Logging
BACKEND-124
Add Request Correlation
BACKEND-125
Expose Application Health Checks
BACKEND-126
Add Application Metrics
Epic 9 — Delivery
BACKEND-127
Containerize the Application
BACKEND-128
Create CI Build and Test Pipeline
This is our initial backlog।
It will evolve, but we should not casually add new product scope।
What Is Missing From the Backlog?
Notice কিছু course topics ticket হিসেবে আলাদা নেই:
Dependency Injection
Spring Beans
HTTP status codes
JPA relationships
JUnit
Mockito
Why?
Because these are learning topics, not product work।
We will learn them while implementing real tickets।
For example:
Spring Dependency Injection
learned while building application components।
JPA
learned while implementing persistence tickets।
JUnit
used while satisfying Definition of Done।
This is a critical course-design principle।
Course Curriculum and Engineering Backlog Are Different
Curriculum says:
What concept does the learner need to understand?
Backlog says:
What does the engineering team need to deliver?
They intersect, but they are not identical।
Example:
Course lesson:
Database Transactions
Engineering ticket:
BACKEND-112
Implement Order Creation Workflow
We teach transaction concepts because the ticket creates a real atomicity problem।
Technology serves work, rather than work being invented merely to demonstrate technology।
Backlog Refinement
Backlog creation is not one-time work।
Before picking a ticket, team may refine it।
Refinement can include:
clarifying scope
adding acceptance criteria
identifying dependencies
splitting oversized work
removing unnecessary work
raising technical questions
For example, BACKEND-112 may initially be too broad।
After RFC/design, we may discover a clean split।
Then split it।
This is normal।
Don't Split Before You Understand the Design
If we split too early:
BACKEND-X
Lock inventory row
BACKEND-Y
Use transaction propagation X
BACKEND-Z
Add repository method Y
we have already assumed implementation।
Better:
Understand design
↓
Choose solution
↓
Break implementation work
Backlog refinement and design inform each other।
Ready Ticket Example
A reasonably ready ticket:
# BACKEND-106 — Expose Available Product Browsing
## Context
Customers need to browse products that can currently be ordered.
## Scope
Expose a REST API for bounded retrieval of products available for ordering.
## Acceptance Criteria
- Only orderable products are returned.
- Product price is included.
- Retrieval is bounded/paginated.
- Inactive products are not presented as orderable.
## Out of Scope
- Product search
- Recommendations
- Categories
- Full-text filtering
## Dependencies
- BACKEND-104
An engineer can understand what is expected without guessing hidden features।
Not-Ready Ticket Example
# BACKEND-118 — Implement Order Payment Workflow
## Open Questions
- Exact provider idempotency behaviour is not yet confirmed.
- Timeout/retry semantics require integration design.
This ticket may exist in backlog but should not be started yet।
That is better than pretending uncertainty does not exist।
Backlog Priority Can Change
Suppose while implementing products we discover payment provider integration has a long external dependency lead time।
Team may move payment investigation earlier।
Priority should reflect:
business value
dependencies
risk
uncertainty
not merely ticket number।
Ticket IDs are identifiers, not absolute execution order।
Risk-Driven Planning
Sometimes a risky unknown should be addressed early।
For example:
Can our chosen inventory strategy safely handle concurrent ordering?
If this threatens fundamental order correctness, design should address it before polishing low-risk endpoints।
Good planning balances:
value
+
dependency
+
risk
Avoid Building Infrastructure "Just in Case"
Backlog should not contain:
Add Kafka for future events
Add Redis in case reads become slow
Create Elasticsearch search cluster
Add Kubernetes manifests before deployment requirements exist
Current product requirement does not justify them।
Future possibility is not current requirement।
This discipline matters enormously in real engineering।
Every Ticket Adds Maintenance Cost
A useful mental model:
More functionality
↓
More code
↓
More tests
↓
More operational surface
↓
More future maintenance
So backlog item should earn its existence।
Ask:
Which requirement or engineering need does this work satisfy?
If no clear answer, perhaps it should not be built।
Traceability
Our work now becomes traceable।
Example:
Product Requirement
Customers can browse available products.
↓
STORY-1
Browse Available Products
↓
BACKEND-103
Product Domain
↓
BACKEND-104
Product Persistence
↓
BACKEND-106
Product Browsing API
↓
Pull Requests
↓
Tests
Similarly:
Product Requirement
Customers can place orders.
↓
STORY-2
Create an Order
↓
BACKEND-110
Order Domain
↓
BACKEND-111
Order Persistence
↓
BACKEND-112
Order Creation Workflow
↓
BACKEND-113
Order Creation API
This makes it easier to understand why implementation exists।
Backlog Is Not Architecture
We now have tickets like:
Persist Orders
But backlog does not answer:
What exact tables?
Which Java classes?
Which package structure?
Where is transaction boundary?
How do modules depend on each other?
Those are technical design questions।
That is exactly why Module 2 comes next।
Our First Planned Milestone
A reasonable first product milestone could be:
Application starts
+
PostgreSQL works
+
Products can be managed
+
Available products can be browsed
This gives us a complete small vertical capability before orders।
Then next milestone:
Inventory management
+
Order creation
Then:
Order history
+
Cancellation
Then:
Security enforcement
+
Payment
The exact release boundary later may vary, but incremental milestones keep progress visible।
What "Milestone" Means Here
Milestone is not a new product feature।
It groups related completed work into an observable project state।
Example:
Milestone 1:
Catalog foundation works.
This is useful for learning too।
Learner can see project evolve rather than waiting until the final lesson for something runnable।
Backlog and Definition of Done Work Together
Ticket tells us:
What change are we making?
Acceptance Criteria tells us:
What behaviour must it satisfy?
Definition of Done tells us:
What quality conditions must be met?
Together:
Ticket
+
Acceptance Criteria
+
Definition of Done
↓
Meaningful engineering work
A Ticket Is Not Done Because Every Subtask Is Checked
Suppose ticket has checklist:
[x] controller
[x] service
[x] repository
[x] migration
but customer can still order inactive product।
Then feature not Done।
Subtasks track implementation activity।
Acceptance criteria track behaviour।
Behaviour wins।
Avoid Ticket-Driven Design
Another trap:
Ticket says create repository.
Therefore repository must exist.
But after design we may realize different structure is better।
Tickets should be refined when understanding improves।
We should not preserve bad implementation idea just because it was written in a backlog earlier।
The Backlog Is a Planning Tool, Not a Contract With the Universe
Backlog may change because:
requirements change
technical discovery happens
dependencies shift
risks appear
tickets are split
tickets become unnecessary
But changes should be deliberate।
We will not randomly rewrite course scope or add features without a reason।
Our Module 1 Deliverables
At the end of Module 1, conceptually our project now has:
Product Brief
Requirement Analysis
Functional Requirements
Non-Functional Concerns
User Stories
Acceptance Criteria
Engineering Context
Definition of Done
Initial Engineering Backlog
This is a substantial amount of engineering preparation।
But importantly, none of it is paperwork for its own sake।
Each artifact answers a different question।
What Each Artifact Answers
Product Brief
What problem and capabilities does the business want?
Requirement Analysis
What is known, ambiguous, risky, or missing?
User Stories
Who needs what and why?
Acceptance Criteria
What behaviour must be true?
Engineering Context
What environment and constraints are we building within?
Definition of Done
What quality bar defines completion?
Backlog
What engineering work do we currently expect to perform?
This separation keeps thinking clear।
What Comes Next
We should still not open the IDE and randomly start coding.
Our backlog now tells us what work exists।
But before implementing the core system we need to answer:
How should the system be designed?
That is the purpose of Module 2.
We will move from:
Requirements
+
Engineering Context
+
Backlog
to:
Technical Design
We will identify:
- domain entities
- system responsibilities
- initial architecture
- important boundaries
- key technical decisions
- risks and alternatives
Then we will write our first RFC and record important decisions through ADRs।
Only after that will Spring Boot implementation properly begin।
Engineering Principle
এই lesson-এর core principle:
Break work into the smallest units that remain meaningful, coherent, testable, and reviewable.
Not:
one ticket for the entire project
and not:
one ticket for every line of code
A good backlog creates clarity without creating bureaucracy।
আরেকটি principle:
The backlog should describe work required by the product and engineering context—not technologies we hope to use someday.
Summary
এই lesson-এ আমরা শিখেছি:
- Product stories এবং engineering tickets এক জিনিস নয়।
- Backlog product requirement-কে actionable engineering work-এ translate করে।
- Good ticket bounded, coherent, reviewable এবং testable।
- Ticket খুব বড় বা unnecessarily tiny—দুটোই problematic।
- Dependencies implementation order influence করে।
- Minimal foundation work feature implementation-এর আগে প্রয়োজন।
- Feature work যেখানে possible vertical slice হিসেবে করা useful।
- Testing প্রতিটি relevant ticket-এর Definition of Done-এর অংশ; শেষে আলাদা "add tests" phase নয়।
- Documentationও change-এর সঙ্গে evolve করা উচিত।
- Ticket should explain why the change exists।