← Extractions

Understanding Coupling — Łukasz Szydło at wroclove.rb 2018

Łukasz Szydło presents a framework for discussing software design precisely, introducing a five-level coupling metaphor (people in a company: local method, local instance, external instance, configurable instance, notification) built on the three kinds of linguistic messages — commands, queries, events. He argues design evaluation requires defining context (business, project, quality attributes) plus precise attribute description, and that coupling is neither inherently good nor bad but context-dependent.

Model
claude-opus-4-7
Ingestion
f8fbbf6c
Input tokens
120,505
fresh
51,205
cached
59,529
cache write
9,771
Output tokens
6,383
Duration
98.5s
Roundtrips
5
Tool calls
12
Cost
$0.00
Nodes/edges extracted
12 / 21
Read set (nodes/edges)
72 / 2

Nodes (12)

update Łukasz Szydło person
attrs (empty) → {"roles" => "programmer, architect, trainer, consultant", "specialties" => "DDD, architecture, continuous delivery"}
description Conference speaker. → Polish programmer, architect, trainer and consultant who helps companies improve their software. Specialties include ...
short_description Conference speaker. → Polish programmer, architect, trainer and consultant specializing in DDD and architecture.
update Understanding coupling talk
attrs {"type" => "talk"} → {"type" => "talk", "duration_minutes" => "45"}
description Talk at wroclove.rb 2018. → Talk by Łukasz Szydło at wroclove.rb 2018. Follows the fictional team lead 'Guido Instinctive' who struggles to evalu...
short_description Talk at wroclove.rb 2018. → Talk at wroclove.rb 2018 on evaluating software design via five levels of coupling.
create Coupling concept
kind (empty) → concept
name (empty) → Coupling
slug (empty) → coupling
attrs (empty) → {"category" => "practice"}
description (empty) → A design quality describing how tightly two software elements depend on each other. In Szydło's framing, coupling bet...
short_description (empty) → Degree of interdependence between software elements; a design attribute with multiple levels.
create Architecture Drivers concept
kind (empty) → concept
name (empty) → Architecture Drivers
slug (empty) → architecture-drivers
attrs (empty) → {"category" => "methodology"}
description (empty) → Szydło's three-part definition of context needed to evaluate any software design: (1) business context — goals, visio...
short_description (empty) → Business context, project context, and quality attributes that frame any design evaluation.
create Commands, Queries, and Events concept
kind (empty) → concept
name (empty) → Commands, Queries, and Events
slug (empty) → commands-queries-and-events
attrs (empty) → {"category" => "pattern"}
description (empty) → Szydło's linguistic grounding for object-oriented messaging: in any language, a person can only build three kinds of ...
short_description (empty) → The three kinds of messages objects can exchange, mirroring linguistic sentence types.
create Dependency Injection concept
kind (empty) → concept
name (empty) → Dependency Injection
slug (empty) → dependency-injection
attrs (empty) → {"category" => "pattern"}
description (empty) → Technique for decreasing coupling by configuring an object's collaborators from the outside. Szydło reframes dependen...
short_description (empty) → Passing collaborators into an object from outside rather than constructing them internally.
create Tacit Knowledge concept
kind (empty) → concept
name (empty) → Tacit Knowledge
slug (empty) → tacit-knowledge
attrs (empty) → {"category" => "methodology"}
description (empty) → Psychological/philosophical concept Szydło invokes in the Q&A: knowledge experienced architects hold that cannot be a...
short_description (empty) → Experience-based knowledge that cannot be fully expressed in words.
create Design Must Be Described Precisely Before It Can Be Improved takeaway
kind (empty) → takeaway
name (empty) → Design Must Be Described Precisely Before It Can Be Improved
slug (empty) → design-must-be-described-precisely-before-it-can-be-improved
attrs (empty) → {"type" => "lesson-learned"}
description (empty) → Core lesson of the talk: design is abstract and hard to discuss, so teams drift into vague comments like 'it looks ok...
short_description (empty) → Learn vocabulary for design first; better design follows precise communication.
create Coupling Is Neither Good Nor Bad takeaway
kind (empty) → takeaway
name (empty) → Coupling Is Neither Good Nor Bad
slug (empty) → coupling-is-neither-good-nor-bad
attrs (empty) → {"type" => "insight"}
description (empty) → Szydło rejects the reflex that loose coupling is always better. Coupling is like gravity — just a force. High couplin...
short_description (empty) → Coupling is a context-dependent force like gravity — sometimes high, sometimes loose.
create Metrics Alone Don't Fix a Coupled Legacy Codebase takeaway
kind (empty) → takeaway
name (empty) → Metrics Alone Don't Fix a Coupled Legacy Codebase
slug (empty) → metrics-alone-don-t-fix-a-coupled-legacy-codebase
attrs (empty) → {"type" => "insight"}
description (empty) → Szydło's answer to the question of how to detect coupling in an existing large project: coupling metrics exist but in...
short_description (empty) → Coupling metrics are overwhelmed on legacy projects; precise communication matters more.
create How to detect coupling in a large existing project? question
kind (empty) → question
name (empty) → How to detect coupling in a large existing project?
slug (empty) → how-to-detect-coupling-in-a-large-existing-project
attrs (empty) → {"answer_summary" => "Metrics exist but are useless on badly-coupled legacy code. Use precise design vocabulary as an...
description (empty) → Audience member asks how to massively detect coupling on a big project you've just joined. Szydło: theoretical answer...
short_description (empty) → Strategy for evaluating coupling when joining a big legacy codebase.
create Does experienced architect's intuition override precise design vocabulary? question
kind (empty) → question
name (empty) → Does experienced architect's intuition override precise design vocabulary?
slug (empty) → does-experienced-architect-s-intuition-override-precise-design-vocabulary
attrs (empty) → {"answer_summary" => "Intuition (tacit knowledge) is real and valuable, but doesn't replace precise vocabulary — team...
description (empty) → Audience member argues experienced architects can correct customer requirements intuitively. Szydło agrees — he belie...
short_description (empty) → Whether experience/intuition can replace explicit design-quality description.

Edges (21)

update Łukasz Szydło → authored → Understanding coupling
context (empty) → Delivered the talk at wroclove.rb 2018.
update Understanding coupling → presented_at → wroclove.rb 2018
context (empty) → Talk presented at the wroclove.rb 2018 conference.
create Łukasz Szydło → attended → wroclove.rb 2018
context (empty) → Speaker at the conference.
relation (empty) → attended
source_node_id (empty) → a748753a-b5e0-43fa-b915-dfda4d5527e8
target_node_id (empty) → 9243ef2c-21bb-4f23-b450-9ecd87882dfe
create Łukasz Szydło → has_skill → Domain-Driven Design
attrs (empty) → {"level" => "expert"}
context (empty) → Listed as one of his specialties.
relation (empty) → has_skill
source_node_id (empty) → a748753a-b5e0-43fa-b915-dfda4d5527e8
target_node_id (empty) → 6e2f88bd-e521-41a3-91d4-aeb5f8fd2486
create Understanding coupling → about → Coupling
context (empty) → The talk is a framework for discussing and evaluating coupling.
relation (empty) → about
source_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
target_node_id (empty) → f74165f3-dae3-4470-a25f-cb314ece3e03
create Understanding coupling → about → Architecture Drivers
context (empty) → Defines context for design evaluation as business context, project context, and quality attributes.
relation (empty) → about
source_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
target_node_id (empty) → 98a55e8d-d1e0-43c1-810c-03071d25018c
create Understanding coupling → about → Commands, Queries, and Events
context (empty) → Grounds object messages in the three linguistic sentence types.
relation (empty) → about
source_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
target_node_id (empty) → 7c04796a-bf02-4248-80f0-a63be3541234
create Understanding coupling → about → Dependency Injection
context (empty) → Reframed as the 'configurable instance' level of coupling.
relation (empty) → about
source_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
target_node_id (empty) → 06941a97-6c62-4450-8f9a-16cf172f5dd8
create Understanding coupling → about → Tacit Knowledge
context (empty) → Invoked in the Q&A to reconcile intuition with precise vocabulary.
relation (empty) → about
source_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
target_node_id (empty) → 0d9d68d4-e448-4719-814c-f6d314105ddf
create Design Must Be Described Precisely Before It Can Be Improved → from_talk → Understanding coupling
context (empty) → Closing lesson of the talk.
relation (empty) → from_talk
source_node_id (empty) → baae07a8-b625-4979-bba9-213d0f498fda
target_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
create Coupling Is Neither Good Nor Bad → from_talk → Understanding coupling
context (empty) → Summary point near the end of the talk.
relation (empty) → from_talk
source_node_id (empty) → 216fcc08-ddac-4716-9f3b-0bda7b79eaf0
target_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
create Metrics Alone Don't Fix a Coupled Legacy Codebase → from_talk → Understanding coupling
context (empty) → Answer given in the Q&A.
relation (empty) → from_talk
source_node_id (empty) → bf095e66-6fb5-4e88-9a2a-ba8a61ed366f
target_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
create Design Must Be Described Precisely Before It Can Be Improved → about → Coupling
context (empty) → Lesson illustrated with the coupling vocabulary built in the talk.
relation (empty) → about
source_node_id (empty) → baae07a8-b625-4979-bba9-213d0f498fda
target_node_id (empty) → f74165f3-dae3-4470-a25f-cb314ece3e03
create Coupling Is Neither Good Nor Bad → about → Coupling
context (empty) → Takeaway is specifically about when to prefer tight vs loose coupling.
relation (empty) → about
source_node_id (empty) → 216fcc08-ddac-4716-9f3b-0bda7b79eaf0
target_node_id (empty) → f74165f3-dae3-4470-a25f-cb314ece3e03
create Metrics Alone Don't Fix a Coupled Legacy Codebase → about → Coupling
context (empty) → Addresses detecting coupling in legacy systems.
relation (empty) → about
source_node_id (empty) → bf095e66-6fb5-4e88-9a2a-ba8a61ed366f
target_node_id (empty) → f74165f3-dae3-4470-a25f-cb314ece3e03
create How to detect coupling in a large existing project? → asked_at → Understanding coupling
context (empty) → Asked in the talk's Q&A.
relation (empty) → asked_at
source_node_id (empty) → 96918794-6a40-4232-8410-7740b9f4c9bc
target_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
create Does experienced architect's intuition override precise design vocabulary? → asked_at → Understanding coupling
context (empty) → Asked in the talk's Q&A.
relation (empty) → asked_at
source_node_id (empty) → de674309-d96b-4d99-a31c-8ce15ed094e7
target_node_id (empty) → e87e4e11-7443-459a-b228-848b6d21662b
create How to detect coupling in a large existing project? → about → Coupling
context (empty) → Question asks about detecting coupling.
relation (empty) → about
source_node_id (empty) → 96918794-6a40-4232-8410-7740b9f4c9bc
target_node_id (empty) → f74165f3-dae3-4470-a25f-cb314ece3e03
create Does experienced architect's intuition override precise design vocabulary? → about → Tacit Knowledge
context (empty) → Question centers on experiential, unspoken knowledge.
relation (empty) → about
source_node_id (empty) → de674309-d96b-4d99-a31c-8ce15ed094e7
target_node_id (empty) → 0d9d68d4-e448-4719-814c-f6d314105ddf
create Coupling → related_to → Commands, Queries, and Events
context (empty) → The five coupling levels are derived by progressively loosening what a sender knows about a receiver, culminating in ...
relation (empty) → related_to
source_node_id (empty) → f74165f3-dae3-4470-a25f-cb314ece3e03
target_node_id (empty) → 7c04796a-bf02-4248-80f0-a63be3541234
create Dependency Injection → related_to → Coupling
context (empty) → DI corresponds to the 'configurable instance' level of coupling.
relation (empty) → related_to
source_node_id (empty) → 06941a97-6c62-4450-8f9a-16cf172f5dd8
target_node_id (empty) → f74165f3-dae3-4470-a25f-cb314ece3e03

Read set

72 nodes

talk Understanding coupling search_nodes+get_node_edges takeaway AI Will Not Replace Developer-Client Empathy search_nodes talk Ever shorter feedback loop search_nodes question How to do DDD remotely? search_nodes tool Sync Space VR search_nodes concept Conway's Law search_nodes concept Weasel Words search_nodes concept Domain Storytelling search_nodes talk Spice up your life with eql search_nodes concept EventStorming search_nodes concept Domain-Driven Design search_nodes resource Implementing Domain-Driven Design search_nodes resource Domain-Driven Design: Tackling Complexity in the Heart of Software search_nodes talk Might & Magic of Domain-Driven Design search_nodes question How to apply DDD when the client refuses to learn ubiquitous language? search_nodes talk The pillars of Domain Driven Design search_nodes concept DDD Whirlpool search_nodes resource Domain-Driven Rails search_nodes person Łukasz Szydło search_nodes person Łukasz Reszke search_nodes person Miron Marczuk search_nodes talk Events events events search_nodes person Karol Szuster search_nodes person Mateusz Nowak search_nodes person Maciej Rząsa search_nodes person Krzysztof Hasiński search_nodes person Agnieszka Małaszkiewicz search_nodes person Jakub Rodzik search_nodes event wroclove.rb 2018 search_nodes event wroclove.rb 2019 search_nodes event wroclove.rb 2024 search_nodes event wroclove.rb 2022 search_nodes event wroclove.rb 2023 search_nodes event wroclove.rb 2026 search_nodes event wroclove.rb 2025 search_nodes talk Counterintuitive Rails pt. 2 search_nodes talk Building LLM powered applications in Ruby search_nodes talk Counterintuitive Rails pt. 1 search_nodes resource Object-Oriented Software Construction search_nodes question Does DDD require object-oriented programming? search_nodes talk Doctrine of Useful Objects Separate Fact from Fiction in OOD search_nodes takeaway Use Refinements for Dependency Reduction search_nodes concept Context Map search_nodes concept Hexagonal Architecture search_nodes concept Breadth-First Search for Code Removal search_nodes concept CQRS search_nodes takeaway Bounded Contexts Are Not Microservices search_nodes takeaway Bounded Contexts Are Natural Microservice Seams search_nodes concept Event-Driven Architecture search_nodes takeaway Risks of DDD: Hierarchy, Perfectionism, Constraints search_nodes concept Waterfall Analysis search_nodes takeaway Replay-Based Debugging search_nodes resource Rocket Real-Time Benchmark search_nodes talk Setup and operation of mutation testing in agentic world search_nodes concept Command UUID Deduplication search_nodes tool RealtimeBoard search_nodes takeaway Time Travel Superpower search_nodes concept Event Store search_nodes tool Ruby Event Store search_nodes question How to persist commands in an event-sourced system? search_nodes talk Working with RailsEventStore in Cashflow Management System search_nodes concept Snapshotting search_nodes project AnyCable search_nodes concept Cynefin Framework search_nodes resource Drive search_nodes takeaway Sign serverlessforruby.org petition search_nodes concept Zero-Disconnect Deployment search_nodes talk Adventures in durable execution search_nodes talk Kamal is not harder than your PaaS search_nodes takeaway Stable commits enable bisect search_nodes concept Real-time Web Applications search_nodes tool webpagetest.org search_nodes

2 edges

talk Understanding coupling presented_at event wroclove.rb 2018
person Łukasz Szydło authored talk Understanding coupling