Skip to content

4Developers 2025: Tomek Ducin - "The many meanings of share and reuse in software architecture."

Tomek Ducin

CommunityPROIDEA Events50 minBeginnerOpen on YouTube ↗

Industry experts analyze emerging threats surrounding 4Developers 2025: Tomek Ducin - "The many meanings of share and reuse in software architecture.".

Summary

### Overview In this presentation from 4Developers 2025, Tomek Ducin explores the concept of sharing and reuse across different levels of software engineering and architecture. Through the narrative journey of a fictional developer named Bożydar—who transitions from a bootcamp graduate during the 2020 pandemic to a senior architect and business-focused leader—the talk examines the trade-offs of code reuse, shared persistence, data modeling, architectural decoupling, and business alignment.

### Key Topics - **Code Reuse vs. Domain Responsibility (DRY vs. WET):** How junior engineers often misinterpret the DRY principle (Don't Repeat Yourself) as a mandate to deduplicate lines of technical code rather than unifying domain knowledge, risking premature abstractions. - **Monorepos and Universal Patterns:** The pitfalls of blindly adopting trending architectures (e.g., monorepos, reducers everywhere) without defining the actual problem, metrics, or trade-offs. - **Shared Persistence vs. Database-per-Service:** Evaluating the consequences of a centralized database across services, including tight coupling, deployment synchronization (release trains, code freezes), versus independent data stores. - **Domain Modeling & Bounded Contexts:** The danger of creating "God Classes" or canonical data models across distinct business subdomains versus separating models using perspectives like being, behaving, and becoming. - **Microservices, Microfrontends, and Team Topologies:** Determining what should actually be shared (observability, UI design systems) versus what should remain strictly decoupled (state, deployments, data schemas), alongside empowering stream-aligned teams by measuring KPI outcomes rather than task velocity. - **Business Capabilities and Value Streams:** Viewing software architecture not as an end goal, but as an enabler for business capabilities and strategic business goals.

### Technical Details - **Integration Patterns:** Clear distinction between Events (facts from the past, declarative statements), Queries (state in the present, questions), and Commands (future intent, imperative instructions that can fail or be rejected). - **Decoupling Release from Deployment:** Leveraging trunk-based development with feature toggles (boolean flags, scalers, or maps) to support canary releases, rolling deployments, and A/B testing without synchronizing database migrations. - **Contextual Optimization:** Choosing technical and architectural trade-offs based explicitly on primary business constraints, such as optimizing for time to market (e.g., meeting regulatory deadlines to avoid penalties) versus performance, cost reduction, or complexity isolation.

### Takeaways - Reuse and sharing always come with a cost, and strict isolation also carries trade-offs; there are no silver bullets in architecture. - Architectural decisions must be framed around asking the right questions: What problem is being solved, how is it measured, and what context has changed? - The ultimate maturity in software engineering lies in aligning technical decisions with business capabilities and recognizing that not every problem requires writing software or building in-house solutions.

Related talks