Passing databases creates accidental coupling and breaks business encapsulation. Passing databases creates accidental coupling and breaks business encapsulation. TL;DR: Don't mix data access concerns with essential business behavior. TL;DR: Don't mix data access concerns with essential business behavior. Problems 😔 Tight Coupling
Mixed responsibilities
Bijection violation
Testability
Business logic pollution
Separation of concerns violation
Blurred Layers
Single Responsibility Principle violation Tight Coupling Coupling Mixed responsibilities Bijection violation Bijection Testability Business logic pollution pollution Separation of concerns violation Blurred Layers Single Responsibility Principle violation Solutions 😃 Use dependency injection
Don't use the Repository Pattern. Find real abstractions instead
Separate business logic
Design for Decoupling Use dependency injection Don't use the Repository Pattern. Find real abstractions instead Repository Pattern Separate business logic Design for Decoupling Refactorings ⚙️ https://hackernoon.com/refactoring-016-building-with-the-essence?embedable=true https://hackernoon.com/refactoring-016-building-with-the-essence?embedable=true https://hackernoon.com/refactoring-018-how-to-replace-a-singleton?embedable=true https://hackernoon.com/refactoring-018-how-to-replace-a-singleton?embedable=true Context 💬 When you pass a database connection or database object directly to business objects, you create accidental coupling between your domain logic and data persistence mechanisms. accidental This approach gives you a false sensation of flexibility while making your code harder to test, maintain, and evolve. The database becomes an implementation detail that leaks into your business layer, violating the separation of concerns principle. Your business objects should focus on essential business rules and behavior, not on accidental logic like how data gets stored or retrieved. This pattern also makes unit testing extremely difficult since you cannot mock or stub the database interactions without complex setup procedures. mock Sample Code 📖 Wrong ❌ class InvoiceProcessor:
    def process_invoice(self, invoice_data, database):
        # Business logic mixed with database access
        customer = database.execute(
            "SELECT * FROM customers WHERE id = ?", 
            invoice_data['customer_id']
        ).fetchone()
        
        if customer['credit_limit'] < invoice_data['amount']:
            raise Exception("Credit limit exceeded")
        
        # More business logic
        tax = invoice_data['amount'] * 0.21
        total = invoice_data['amount'] + tax
        
        # Direct database manipulation
        database.execute(
            "INSERT INTO invoices (customer_id, amount, tax, total) "
            "VALUES (?, ?, ?, ?)",
            (invoice_data['customer_id'], invoice_data['amount'], 
             tax, total)
        )
        
        database.commit()
        return total class InvoiceProcessor:
    def process_invoice(self, invoice_data, database):
        # Business logic mixed with database access
        customer = database.execute(
            "SELECT * FROM customers WHERE id = ?", 
            invoice_data['customer_id']
        ).fetchone()
        
        if customer['credit_limit'] < invoice_data['amount']:
            raise Exception("Credit limit exceeded")
        
        # More business logic
        tax = invoice_data['amount'] * 0.21
        total = invoice_data['amount'] + tax
        
        # Direct database manipulation
        database.execute(
            "INSERT INTO invoices (customer_id, amount, tax, total) "
            "VALUES (?, ?, ?, ?)",
            (invoice_data['customer_id'], invoice_data['amount'], 
             tax, total)
        )
        
        database.commit()
        return total Right 👉 class InvoiceProcessor:
    def __init__(self, billing_ledger):
        self.billing_ledger = billing_ledger
    
    def process_invoice(self, customer, amount):
        # Pure business logic with proper domain objects
        if customer.credit_limit < amount:
            raise CreditLimitExceededException()
        
        # Business calculations
        tax = amount * 0.21
        total = amount + tax
        
        # Create the domain object
        # No repositories are involved
        invoice = Invoice(
            customer=customer,
            amount=amount,
            tax=tax,
            total=total
        )
        
        self.billing_ledger.record(invoice)
        return total class InvoiceProcessor:
    def __init__(self, billing_ledger):
        self.billing_ledger = billing_ledger
    
    def process_invoice(self, customer, amount):
        # Pure business logic with proper domain objects
        if customer.credit_limit < amount:
            raise CreditLimitExceededException()
        
        # Business calculations
        tax = amount * 0.21
        total = amount + tax
        
        # Create the domain object
        # No repositories are involved
        invoice = Invoice(
            customer=customer,
            amount=amount,
            tax=tax,
            total=total
        )
        
        self.billing_ledger.record(invoice)
        return total Detection 🔍 [x]Semi-Automatic [x]Semi-Automatic [x] You can detect this smell when you find database connections, SQL queries, or ORM objects passed as parameters to business methods. Look for method signatures that accept database-related objects or when you see SQL statements mixed with business logic calculations. Static analysis tools can flag methods that receive database connections as parameters, and code reviews should catch these architectural violations. Exceptions 🛑 Low level database access does not cross domain when they pass the database as argument Low level database access does not cross domain when they pass the database as argument Tags 🏷️ Coupling Coupling Level 🔋 Intermediate Intermediate Why the Bijection Is Important 🗺️ Your business objects should model real-world entities and behaviors without knowing about storage mechanisms. real-world entities When you pass databases as parameters, you break the one-to-one correspondence between business concepts and code representation. one-to-one correspondence In the real world, an invoice processor doesn't carry around a database. it works with customers and invoices as business entities. Breaking this bijection creates artificial dependencies that don't exist in the problem domain, making your code harder to understand and maintain. AI Generation 🤖 AI code generators frequently create this smell, suggesting quick solutions that directly couple database access with business logic. They prioritize working code over clean architecture, leading to tightly coupled implementations. AI Detection 🥃 AI tools can detect this smell when you provide clear instructions about the separation of concerns and dependency injection patterns. Try Them! 🛠 Remember: AI Assistants make lots of mistakes Remember: AI Assistants make lots of mistakes Suggested Prompt: Remove the coupling of the database Suggested Prompt: Remove the coupling of the database Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini



DeepSeek

DeepSeek



Meta AI

Meta AI



Grok

Grok



Qwen

Qwen Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini



DeepSeek

DeepSeek



Meta AI

Meta AI



Grok

Grok



Qwen

Qwen Without Proper Instructions

With Specific Instructions Without Proper Instructions Without Proper Instructions With Specific Instructions With Specific Instructions ChatGPT

ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT Claude

Claude Claude Claude Claude Claude Claude Claude Perplexity

Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Copilot

Copilot Copilot Copilot Copilot Copilot Copilot Copilot Gemini

Gemini Gemini Gemini Gemini Gemini Gemini Gemini DeepSeek

DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek DeepSeek Meta AI

Meta AI Meta AI Meta AI Meta AI Meta AI Meta AI Meta AI Grok

Grok Grok Grok Grok Grok Grok Grok Qwen

Qwen Qwen Qwen Qwen Qwen Qwen Qwen Conclusion 🏁 Avoid passing databases as parameters to business objects. This approach keeps your business logic clean, makes testing easier, and maintains proper separation between the domain and infrastructure concerns. Relations 👩‍❤️‍💋‍👨 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-x-i7r34uj https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vi-cmj31om https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vii-8dk31x0 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-vii-8dk31x0 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xiii More Information 📕 https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true https://hackernoon.com/coupling-the-one-and-only-software-designing-problem-9z5a321h?embedable=true https://hackernoon.com/there-are-no-silver-bullets-for-this-werewolf-2t213woi?embedable=true https://hackernoon.com/there-are-no-silver-bullets-for-this-werewolf-2t213woi?embedable=true Disclaimer 📘 Code Smells are my opinion. opinion Credits 🙏 Photo by Josh Appel on Unsplash Josh Appel Unsplash The secret to building large apps is never build large apps. Break your applications into small pieces.  Then, assemble those testable, bite-sized pieces into your big application The secret to building large apps is never build large apps. Break your applications into small pieces.  Then, assemble those testable, bite-sized pieces into your big application Justin Meyer Justin Meyer https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true This article is part of the CodeSmell Series. https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Don't Mix Data Access Concerns With Essential Business Behavior

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Predictions About the Future of Finance

5 Essential Software Architecture Design Principles

A Beautiful Architecture of Server-Side Alarm

A Deeper Look into Clean Architecture: Flutter vs Kotlin

An Introductory Guide to Monolith Software Applications

10 Predictions About the Future of Finance

5 Essential Software Architecture Design Principles

A Beautiful Architecture of Server-Side Alarm

A Deeper Look into Clean Architecture: Flutter vs Kotlin

An Introductory Guide to Monolith Software Applications

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps