Architecture on dplabs — Software Engineering & Technology Consultancy

How to Evaluate Architecture Without Falling in Love With Solutions

Mon, 04 May 2026 00:00:00 +0000

Every engineer who has spent significant time in architecture discussions has seen the same dynamic: a proposed solution is presented, its proponents defend it, critics pick at details, and the group gravitates toward whichever solution has the most enthusiastic advocate rather than the best trade-off profile.

This is not evaluation. It’s preference arbitration.

Effective architecture review requires a framework that separates the emotional investment from the analysis — that forces explicit engagement with dimensions like cost, risk, and reversibility that advocates tend to minimize and critics tend to ignore.

Building AI Features Without Losing Control of Your Architecture

Mon, 06 Apr 2026 00:00:00 +0000

AI features are getting added to production systems quickly — often quickly enough that the usual architectural discipline gets skipped. The integration is direct: OpenAI SDK in the service, API calls scattered through business logic, prompts hardcoded in the calling code.

This works for a proof of concept. At production scale, with real operational requirements, it creates a class of problems that are expensive to fix after the fact.

The Vendor Lock-in Problem

Directly using the OpenAI SDK, the Anthropic SDK, or any provider’s client library throughout your codebase creates tight coupling to that provider’s interface. When you want to:

Spring Boot Dependency Injection Without Losing Your Architecture

Mon, 21 Jul 2025 00:00:00 +0000

Spring’s dependency injection container is one of the most mature and capable DI frameworks available. It’s also capable of enabling architectures that are deeply coupled to Spring internals, impossible to test without a full Spring context, and opaque about their dependencies.

The patterns that produce good Spring Boot architectures are not complicated. They require deliberate choices about when to use Spring and when to step back from it.

Constructor Injection Is Non-Negotiable

Spring supports three injection mechanisms: constructor, setter, and field injection. Field injection (@Autowired on a field) is the most common and the worst.

Security Is an Architecture Concern

Mon, 26 May 2025 00:00:00 +0000

Security gets treated as a feature set: authentication, authorization, input validation, encryption. Implement those features and the system is secure. This framing is wrong and produces systems that are secure in obvious ways while vulnerable in non-obvious ones.

Security is an emergent property of architectural decisions: where trust boundaries are placed, how data flows between components, what permissions components have, how failures are handled. These decisions are made during design, not during a security review at the end.

Technical Debt: Not All Debt Is Bad

Mon, 03 Mar 2025 00:00:00 +0000

Ward Cunningham introduced the technical debt metaphor to explain to non-technical stakeholders why code needed to be refactored. The analogy to financial debt was deliberate: sometimes you borrow money to move faster, and the interest compounds over time until the debt needs to be paid.

Over time, the metaphor has been stretched to cover every imperfect thing in a codebase. This is not useful. Not all debt is the same. Not all debt should be paid down.

Monolith vs Microservices: Starting With the Right Question

Mon, 06 Jan 2025 00:00:00 +0000

The monolith vs microservices debate has produced more heat than light over the past decade. Both sides have oversimplified. “Monoliths don’t scale” is demonstrably false — StackOverflow ran a monolith for years serving massive traffic. “Microservices are only for large teams” ignores the many small teams that have shipped them successfully.

The real question is not which architecture is better in the abstract. It’s which architecture fits your current constraints: your team size, your organizational structure, your operational maturity, and your actual scaling requirements.

Event-Driven Architecture: When Events Help and When They Hurt

Mon, 23 Dec 2024 00:00:00 +0000

Event-driven architecture has become fashionable, which means it’s being applied in situations where it doesn’t fit. Events are a powerful architectural tool for specific problems. They’re a significant operational burden when applied indiscriminately.

Understanding when events help and when they hurt requires understanding what problems they actually solve.

Events vs Commands

The distinction matters more than most tutorials acknowledge.

A command expresses intent: “place this order,” “cancel this payment,” “reserve this inventory item.” It’s addressed to a specific recipient and implies that recipient is responsible for handling it. Commands can be rejected. They have an expected response.

Modern Spring Boot Architecture: Beyond the Three-Layer Application

Mon, 02 Dec 2024 00:00:00 +0000

The three-layer architecture — controllers, services, repositories — is how most Spring Boot tutorials present application structure. It’s a reasonable starting point. It’s also a pattern that breaks down as applications grow.

The problems are predictable: services become God classes with hundreds of methods, repository calls leak into controllers, domain logic spreads across multiple layers, and changing anything requires understanding the entire application at once. The layered architecture doesn’t enforce boundaries — it suggests them. Suggestions decay under deadline pressure.

Architecture Decision Records: Making Technical Decisions Explicit

Mon, 11 Nov 2024 00:00:00 +0000

Every significant technical decision your team makes will be questioned later. When the original authors have left. When the context has changed. When someone proposes replacing the system. When a new engineer asks “why does this work like this?”

Most teams have no good answer to these questions. The reasons behind decisions live in people’s heads, in Slack threads that are impossible to find, or nowhere at all.

Architecture Decision Records are a lightweight practice that fixes this. They capture not just what was decided, but why — including what was considered and rejected. The investment is small. The return compounds over time.

Distributed Systems: The Problems You Get for Free

Mon, 28 Oct 2024 00:00:00 +0000

Every system that communicates over a network is a distributed system, and distributed systems fail in ways that single-process applications don’t. This is not opinion — it’s physics. Networks drop packets. Clocks drift. Services restart. Disks fail. These things happen regardless of how carefully you write your application code.

The teams that get distributed systems right don’t eliminate these failures. They design so that their systems remain correct despite them.

The Modular Monolith: An Architecture Pattern That Deserves More Attention

Mon, 14 Oct 2024 00:00:00 +0000

The software industry has a microservices fixation. Over the last decade, “monolith” became almost a pejorative, and teams moved to distributed architectures before they had the scale, team size, or operational maturity to justify them.

The result has been widespread over-engineering: systems that are harder to understand, harder to debug, harder to change, and more expensive to operate — not because distributed systems are inherently bad, but because the problems they solve weren’t actually present.