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

Microsoft Azure Well-Architected Framework - Reliability

Reliability is a foundational pillar when building resilient systems, especially for critical components. Outages and malfunctions pose serious risks to any workload, so a truly reliable system must be designed to detect, withstand, and recover from failures within an acceptable timeframe. It must ensure continued functionality and maintain availability so that users can access services as expected, both in terms of uptime and quality. 🔧 Aligned with Azure’s Reliability Checklist Keep it simple and efficient Strive for a solution that meets requirements without unnecessary complexity—simplicity simplifies reliability Identify and prioritize flows Map out user and system flows, assess their criticality, and focus engineering efforts on those with the highest business impact Conduct failure mode analysis (FMA) Investigate every dependency and component with a methodical FMA to uncover weak points, and design mitigation strategies accordingly Define clear reliability and r...
Post a Comment
Read more