Don't Mix Data Access Concerns With Essential Business Behavior

Passing databases creates accidental coupling and breaks business encapsulation.

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

Solutions 😃

1. Use dependency injection
2. Don't use the Repository Pattern. Find real abstractions instead
3. Separate business logic
4. Design for Decoupling

Refactorings ⚙️

https://hackernoon.com/refactoring-016-building-with-the-essence?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.

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.

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

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

Detection 🔍

• [x]Semi-Automatic

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

Tags 🏷️

• Coupling

Level 🔋

• Intermediate

Why the Bijection Is Important 🗺️

Your business objects should model real-world entities and behaviors without knowing about storage mechanisms.

When you pass databases as parameters, you break the one-to-one correspondence between business concepts and code representation.

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

Suggested Prompt: Remove the coupling of the database

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-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-xiii

More Information 📕

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

Disclaimer 📘

Code Smells are my opinion.

Credits 🙏

Photo by Josh Appel on 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

Justin Meyer

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