Unit 01.04: Deciding what to keep outside the framework

The single most useful architectural decision in a LangChain project is which parts do not go in it.

What survives a framework swap

Anything you would need to keep if you replaced the framework tomorrow belongs outside it. That is most of what makes the system correct.

The code sorts six concerns into inside and outside.

DECISIONS = [
    ("business rules and thresholds", "outside", "must be testable and auditable"),
    ("prompt templates",              "inside",  "that is what they are for"),
    ("retry and backoff policy",      "outside", "you need to control the behaviour"),
    ("output validation",             "outside", "your schema, your rules"),
    ("provider selection",            "inside",  "the abstraction earns its place"),
    ("logging and metrics",           "outside", "must survive a framework change"),
]

print(f"{'concern':32} {'lives':9} why")
for concern, where, why in DECISIONS:
    print(f"{concern:32} {where:9} {why}")

outside = sum(1 for _, w, _ in DECISIONS if w == "outside")
print(f"\n{outside} of {len(DECISIONS)} belong in your own code")

# The rule: anything you would need to keep if you replaced the framework
# tomorrow belongs outside it. That is most of the things that make the system
# correct, and it is why a framework swap should be an afternoon, not a rewrite.

Four of six belong in your own code: business rules, retry policy, output validation, and logging. Each is something you need to be able to test, audit, and keep.

Prompt templates and provider selection go inside, because they are precisely what the framework is for. That split is what makes a framework swap an afternoon's work rather than a rewrite - the parts that encode your decisions never moved.

The mistake this prevents

The mistake is using the framework's retry and validation helpers because they are there. They are reasonable, and they mean your retry policy is now a framework behaviour rather than a documented decision - so a version bump can change how many times you call a paid API.

Takeaway

Keep business rules, retries, validation and logging in your own code. If you would need it after a framework swap, it should not depend on the framework.

Mark complete