Systems Need Seams, Not Giant Blobs
What this concept is
As software grows, one of the biggest cleanliness wins is separating construction, configuration, and cross-cutting concerns from core business behavior. Systems stay flexible when they have seams where responsibilities can change independently.
Why it matters here
You do not need enterprise architecture yet, but you do need the habit of not stuffing setup, wiring, logging, persistence, and business rules into the same place.
Concrete example
Weak composition:
def run_app():
db = Database(os.environ["DB_URL"])
logger = Logger(...)
service = BillingService(db, logger)
...
That may be acceptable in a composition root, but it becomes messy if the same wiring logic spreads through business code. A seam keeps setup at the edge and behavior in focused units.
Common confusion / misconception
Adding seams does not mean introducing frameworks or abstract factories everywhere. It means choosing a clean place for wiring and a clean place for behavior. Keep the mechanism proportional to the problem.
How to use it
Prefer:
- explicit boundaries between setup and use
- dependency injection where it clarifies control
- wrappers for cross-cutting concerns instead of scattered repeated logic
- avoiding one giant module that knows everything
Check yourself
What is the difference between a useful seam and unnecessary abstraction?
Mini drill or application
Look at one file that both creates dependencies and performs business logic. Mark which lines belong to wiring and which belong to behavior. Sketch how you would separate them.