Skip to main content

"Dushnylo" Series: Introduction and the first episode.


Lately, I've noticed a recurring and perplexing theme in numerous posts and articles. Certain tech authorities assert that some established patterns are superfluous. For instance: "The repository pattern is unnecessary; simply use the ORM directly within your business logic—no need for abstractions."

Therefore, I've chosen to initiate a new series titled “Dushnylo” (Definition: An individual who is excessively critical, focuses on minute details, and overwhelms others with arguments about why something is incorrect or flawed.)

The inaugural topic in the “Dushnylo” series: "Reduced Abstraction, Increased Direct ORM Usage in Business Logic"

Why circumventing abstractions breeds disorder:

Strong Coupling and Reduced Testability

By directly integrating an ORM into your business logic, you create a strong dependency between your business layer and the database implementation. This strategy:

  • Makes migrating to a different ORM or database significantly more challenging.
  • Makes unit testing more complex due to the difficulty in mocking the database.

Elevated Code Duplication and Increased Error Probability

Without a suitable abstraction layer (such as a repository pattern), you will find yourself duplicating the same database operations in various locations. This:

  • Increases the likelihood of inconsistencies and defects.
  • Results in greater maintenance expenses.

Breach of the Single Responsibility Principle (SRP)

Incorporating database logic directly into business logic violates SRP because:

  • Business services should manage business rules, not database operations.
  • Database logic should be contained within specific components or patterns (e.g., repositories, data mappers).

In summary:

While numerous approaches and patterns exist for structuring code, permitting database operations directly within business logic without abstraction is a guaranteed route to disarray. It will create significant problems in maintainability, testing, and future growth.

Let's create scalable, well-organized architectures—not justifications. 😉 

Labels:

Comments

Post a Comment

Popular posts from this blog

Microsoft Azure Well-Architected Framework - Maturity models

The Azure Well-Architected Framework has always been a great way to assess and review workloads. But with the recent updates—especially the introduction of maturity levels —it’s becoming much more than just a checklist. 💡 It’s evolving into a concept. Not only can teams review their architecture, but they can now score, track progress, and continuously improve . The maturity model provides clear stages—from establishing a solid foundation to achieving future-proof agility—making it easier to understand where you are today and where you should aim tomorrow. Why is this important? ✅ It transforms reviews into a roadmap for growth ✅ It allows measurable scoring of architecture maturity ✅ It pushes teams to focus not only on compliance, but also on resilience, agility, and future-readiness Each update makes the Azure Well-Architected Framework better and stronger —helping organizations align technology decisions with long-term business success. 👉 In my view, this is the right dire...
Post a Comment
Read more

Coinbase x402 is great option for paymant per request!

  🚀 What is Coinbase x402? x402 is a new open payment protocol built by Coinbase that revives the long-forgotten HTTP 402 “Payment Required” status and turns it into a modern, internet-native payment layer . Using stablecoins (such as USDC ) directly over HTTP, x402 allows services: APIs, websites, or digital content platforms to charge per request. At the same time,  clients (including AI agents and automated systems ) can pay programmatically , without accounts, subscriptions, or human interaction. In simple terms: request → pay → get response , all at the protocol level. How It Works (Simplified) A client requests a protected resource (API, data, article, service). The server responds with HTTP 402 Payment Required , including payment instructions. The client (app or AI agent) generates a payment transaction using its wallet. The client resends the request with payment details included in HTTP headers. The server verifies the payment and immediately ret...
Post a Comment
Read more

"Dushnylo" Series: What do you know about "Logging-Oriented Programming"

I’ve seen it too many times: developers don’t know how to use logging correctly. We end up with tons of logs, everything dumped in, debug left in production, and  even API keys and secrets leaking out. Why does this still happen? Because we’ve slipped into LOP  (Logging-Oriented Programming) . Just throw in logs everywhere and hope: “we will see what happens here.” WHY WHY WHY!!! The real reason? Most of the time, we are just tired and don’t know how to debug locally. Maybe it needs a 3rd-party integration, maybe we can’t prepare the right data, maybe something else. I’m not asking you to “please use logs correctly.” If you need to debug your code, configure remote debugging or run it locally. So, just: 🚨 Do NOT use LOP. Be a good Software Engineer! 🚨
Post a Comment
Read more