DEV Community: Mostafijur Rahman

I Thought Domain-Driven Design Was a Waste of Time. I Was Wrong.

Mostafijur Rahman — Fri, 22 May 2026 10:33:11 +0000

The first time someone explained Domain-Driven Design (DDD) to me, I thought it was a lot of ceremony for very little payoff.

Aggregates, value objects, bounded contexts — a whole vocabulary to learn. I had shipped plenty of features without any of it. My honest assumption: this will just slow me down.

I was wrong. Here's the short version of how I found out.

The project that changed my mind

I worked on a system with a hierarchy — Site, then Aggregator, then a unit under that. A "plan" existed at every level.

In the code, all three were just plan. Same name, same shared object, everywhere.

It worked — until it didn't. Features started colliding. A change to one level's plan quietly broke another. Every function needed a comment explaining which plan it meant. New people asked the same question every week: "is this the site plan or the unit plan?"

The code ran fine. The understanding around it was rotting.

That's the exact problem DDD is built to fix.

What DDD actually is

DDD is not a framework. Nothing to install. It's a discipline: design your software around the business problem, not the database or the framework.

The patterns get all the attention, but the real value is in two boring ideas.

1. Ubiquitous language — name things honestly

Pick precise words and use them everywhere — in conversations, tickets, and the code itself.

If the business has a "draft plan" and a "submitted plan," those exact words belong in your class names. Not plan with a vague status field. The moment a name is vague, logic starts hiding inside it.

My entire mess traced back to one overloaded word.

2. Bounded context — stop forcing one model

"Customer" means different things to billing, support, and analytics. Forcing one shared Customer class gives you 40 fields nobody dares touch.

A bounded context is a line you draw: inside this boundary, a word means exactly one thing. Cross the line, you're allowed a different model.

This is also the most reliable way to answer "how do I split this microservice?" — split where the domain actually splits.

The patterns, in one line each

Entity — has a stable identity over time (an order stays that order).
Value object — defined only by its values (money, a date range).
Aggregate — a group of objects with one entry point that enforces the rules.
Repository — hides how data is stored from your domain code.
Domain event — something meaningful happened (PlanSubmitted).

But these only make sense after the language and boundary work. Reach for them first and you get fancy code that models nothing real.

When to skip DDD

My old skepticism wasn't wrong — just aimed at the wrong project.

Skip DDD if: the app is simple CRUD, the project is small or short-lived, or the complexity is technical (algorithms, performance) rather than business logic.

Use DDD if: the domain is genuinely complex and the software has to live and evolve for years.

"This will slow me down" is correct — for simple projects. It's completely wrong for complex ones.

What I'd tell my earlier self

The patterns are not the point. You can memorize aggregates and value objects and still build a mess.

The point is the boring stuff: talk to the people who understand the business, agree on exact words, draw honest boundaries, and let the code follow.

DDD is overhead. On a simple project, bad trade. On a complex one meant to last, it's the cheapest insurance you'll ever buy.

Originally published on mrsajib.com. I write weekly about backend engineering and building software that lasts.

AI Will Replace Backend Developers? A Python Engineer's Honest Take

Mostafijur Rahman — Thu, 07 May 2026 16:29:47 +0000

Everyone is talking about AI replacing developers.

Some people are scared. Some people laugh it off. Most people just don't know what to believe.

I've been a backend engineer for 6 years. I write Python every day. I build APIs, real-time systems, and production backends. And honestly? I was worried too — until I actually started paying attention to what's happening on the ground.

Let me share what I've seen. No hype. No fear. Just real experience.

Yes, I Use AI Tools Every Day

I'm not going to pretend I don't use AI. I use GitHub Copilot and Claude Code daily.

They help me move faster. Repetitive tasks that used to take 30 minutes now take 5. Boilerplate code, basic CRUD, writing tests — AI handles these really well.

But here's the thing I noticed early on:

I never just trust what AI gives me.

Every single time, I review it. I test it. I make sure it actually fits the system I'm building — not just some generic example from the internet. Because AI doesn't know my system. Only I do.

That one habit — reviewing AI output instead of blindly copying it — is what separates engineers who grow with AI from those who get burned by it.

The Night My Production API Crashed

Let me tell you about a night I'll never forget.

It was around 2 AM. My client messaged me — the server was down. Production. Real users. Real impact.

I jumped on my laptop immediately.

I checked the logs. Dug through the errors. And there it was — a concurrency bug. Multiple requests were hitting the same database row at the same time, causing a race condition that Django wasn't handling cleanly.

I fixed it using select_for_update() — a database-level lock that made sure only one request could modify that row at a time. Crisis over.

Now here's my question:

Could AI have fixed that at 2 AM?

Maybe AI could have suggested select_for_update() if I described the problem perfectly. But finding the problem in the first place? Understanding why that specific bug was happening in that specific system under that specific load? That took 6 years of experience. That took knowing the codebase. That took staying calm under pressure and thinking clearly when everything is on fire.

No AI tool was going to wake up and fix that for my client. I was.

What AI Actually Cannot Do

After 6 years of real production work, here is what I have learned AI genuinely struggles with:

Understanding your business context

When I build a system, I need to understand why it needs to work a certain way — not just how. AI doesn't sit in client meetings. It doesn't ask the right questions. It doesn't know that your client's team works across time zones and needs very specific workflows.

Making architecture decisions

PostgreSQL or DynamoDB? Microservice or monolith? WebSocket or polling? These decisions have consequences that last years. They depend on team size, budget, and where the product is going. AI can give you options — but it cannot make the right call for your specific situation.

Debugging complex production issues

Race conditions. Memory leaks. Concurrency bugs at 2 AM. These are not problems you solve by copy-pasting into ChatGPT. They need deep system knowledge, real experience, and sometimes — a lot of patience when everything is breaking at once.

Taking responsibility

When production breaks, someone has to own it. Lead the fix. Talk to the client. Make sure it never happens again. AI tools have zero accountability. They cannot be on-call. They cannot look a client in the eye and say "I've got this."

So What Is Really Happening?

Here is my honest take:

AI is not replacing backend developers. It is replacing developers who refuse to grow.

Developers who only write basic APIs with no systems thinking? They will struggle.

Developers who understand distributed systems, concurrency, data modeling, and business logic — and also know how to use AI tools effectively? They are becoming more valuable than ever.

The data backs this up. Software engineering job postings in 2026 are at a 3-year high. Companies are not hiring fewer engineers — they are hiring better ones.

The Real Danger Is Not AI

The real danger is staying the same while everything around you changes.

If you are still writing the same code the same way you did 3 years ago — that is the actual threat to your career.

The engineers winning right now are the ones who:

Use AI to move faster — not as a replacement for thinking
Build deep expertise in systems design and architecture
Understand the business, not just the code
Communicate clearly when things go wrong
Never stop learning

My Honest Advice

Use AI tools. Use them every day. But never stop building your own depth.

Because the day a really hard bug hits production at 2 AM — your client is not going to call ChatGPT.

They are going to call you.

Make sure you are ready to answer.

By Mostafijur Rahman — Backend Engineer

Originally published at mrsajib.com

Securing Your Django Application: Best Practices for Preventing XSS, CSRF, and More

Mostafijur Rahman — Wed, 25 Sep 2024 16:20:18 +0000

Security should always be at the forefront of any web development project. With Django, you get a framework that provides a lot of built-in security features, but there are still steps you must take to ensure your application is secure. In this post, we'll explore some best practices for preventing common web vulnerabilities such as Cross-Site Scripting (XSS), SQL Injection, Cross-Site Request Forgery (CSRF), and more.

1. XSS Injection and HTML Injection Prevention

Cross-site scripting (XSS) attacks occur when malicious scripts are injected into websites, typically via user input fields. To prevent XSS, you must sanitize all user input by removing dangerous tags, attributes, and scripts. The bleach library was traditionally used for sanitizing input, but it has been deprecated since 2023. A great alternative is html-sanitizer, which can effectively sanitize user input.

In addition to sanitizing input, you should leverage Django's built-in escape filters within templates. These filters ensure that user-generated content is safely escaped, preventing dangerous HTML from rendering.

Be cautious when using Django template tags like is_safe, safe, mark_safe, and especially when auto escaping is turned off. These tools bypass the default escaping mechanisms and should only be used when absolutely necessary.

Implement a Content Security Policy (CSP)
Another layer of protection is to add a Content Security Policy (CSP) to your HTTP headers. A CSP limits which sources are allowed to load content on your site, reducing the risk of XSS attacks. You can implement CSP in Django using middleware like django-csp.

2. Cross-Site Request Forgery (CSRF) Protection

Django provides built-in protection against Cross-Site Request Forgery (CSRF) attacks. This is achieved by ensuring that any form submissions include a secret, user-specific token. When using HTTPS, this protection is further enhanced by verifying the Referer header for same-origin requests.

Avoid Disabling CSRF
While Django allows you to disable CSRF protection for specific views using the @csrf_exempt decorator, be very cautious when doing so. Disabling CSRF protection exposes your application to significant risks. Always prioritize the use of HTTPS and consider enforcing HTTP Strict Transport Security (HSTS) for an additional layer of protection.

3. SQL Injection Protection

Django is well-equipped to handle SQL injection attacks by using parameterized queries. When you work with Django's ORM, user input is automatically escaped, preventing SQL injection vulnerabilities.

However, when you manually execute raw SQL queries using methods like RawSQL or extra(), you must ensure that user-controlled inputs are properly sanitized and escaped. If you are ever in doubt, it's safer to use Django's ORM methods.

4. Clickjacking Protection

Clickjacking is a sneaky attack where a malicious actor hijacks legitimate clicks and routes them to hidden, malicious pages. For instance, a user might think they're clicking a button on a legitimate site, but their clicks are being intercepted by an invisible iframe.

Django provides X-Frame-Options middleware to prevent your site from being embedded within an iframe. This middleware ensures that your site cannot be framed, offering effective protection against clickjacking attacks.

5. Securing Django Sessions

Django sessions are a way to store user-specific data, such as login status. Misconfigured session settings can lead to session hijacking or session fixation attacks. Here are a few key configurations to secure your sessions:

Secure Session Cookies: Ensure session cookies are only transmitted over HTTPS.

SESSION_COOKIE_SECURE = True

HTTPOnly: Prevent JavaScript from accessing session cookies by setting the HttpOnly flag.

SESSION_COOKIE_HTTPONLY = True

Session Expiry: Set a session expiry time to minimize risk.

SESSION_COOKIE_AGE = 1209600  # Two weeks in seconds

6. Man-in-the-Middle Attacks (SSL/TLS)

To protect your users' data from Man-in-the-Middle (MITM) attacks, it's crucial to use encryption via HTTPS. Django can be configured to automatically redirect all HTTP traffic to HTTPS:

SECURE_SSL_REDIRECT = True

You should also enable HTTP Strict Transport Security (HSTS), which ensures that browsers only communicate with your site over HTTPS in the future:

SECURE_HSTS_SECONDS = 31536000  # 1 year
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True

7. Leverage Django's Built-in Security Checklist

Django provides a built-in security checklist that you can run to ensure your project meets security guidelines. This command will scan your settings.py file and provide warnings if you have any misconfigurations that could expose your application to security risks:

python manage.py check --deploy

Make sure to review any warnings or errors and adjust your settings accordingly.

Conclusion

Django offers a robust set of tools and best practices for securing your application. By following the guidelines outlined above, you can significantly reduce the risk of attacks such as XSS, CSRF, SQL injection, and more. Remember, security is not a one-time task—it's an ongoing process of monitoring, patching, and improving.