Feature, Shared, or Library: Drawing the Three Boundaries In short: Feature code knows your business and belongs to one screen. Shared code knows your business and is used across screens. Library code knows nothing about your business at all. Mixing these three is how a folder becomes a liability. The most dangerous directory in a growing repository is usually the one called . Without a rule for what goes in it, becomes the place developers put anything that might be reused. A year later it is a web of dependencies where a tweak to a "shared" button breaks the billing dashboard, the intake form, and the profile page at once. The fix is to recognise that "reusable" is not one thing. It is three. The three tiers Tier Scope Knows business terms? Example The test --- --- --- --- --- 1. Feature One domain or route Yes, freely If I delete this feature, this goes with it 2. Shared Several domains, one app Yes, but generalised Used in three places, still says "Grade A" 3. Library Anything, any app No. None. Could a completely different company use this? Every component, directive, pipe, and service belongs to exactly one of these. Tier 1: Feature code — the default Rule: code lives as close to where it is used as possible. Do not abstract early. If a component is only used on the tanker intake dashboard, it belongs inside the feature and nowhere else. from Chapter 1 is feature code. It knows about litres, it knows about tankers, it uses the capacity warning directive. It should not be reachable from the rest of the application. That isolation is the point: someone can redesign the tanker UI without any chance of breaking milk processing. Tier 2: Shared code — the bridge Some business concepts genuinely span features. "Milk quality" — Grade A, Grade B, Reject — is a core concept in our domain. Tanker intake displays it, lab testing sets it, shipping verifies it. You do not want three teams building three different badges that disagree about what colour "Reject" is. The boundary check: this is reusable across the app, but it is not library code, because is a dairy business concept. Ship this to another company and it is meaningless. Tier 3: Library code — the platform Library code is your design system: buttons, cards, dialogs, tables, form fields. The rule is zero business context. A library component must never know what a tanker, a milk grade, or a payout is. In Chapter 1, had a hardcoded wrapper. Let's pull that structure out into a real Tier 3 component using content projection. Completely generic. No dairy anywhere. Composing the tiers Now refactor the Tier 1 card to sit inside the Tier 3 one: Three tiers, cleanly stacked: the library provides the box, the shared pipe formats the number, the feature knows what a tanker is. The dependency direction There is one rule that makes all of this hold together: Dependencies point downward only. A feature may import shared and library code. Shared may import library code. Library code imports nothing from above it. The moment imports , the library is no longer a library — it is a very awkward part of your application. "But I thought you should extract to shared as soon as two places need it" This is the most reasonable-sounding wrong rule in front-end architecture, and it comes from a good instinct: duplication is bad, so remove it as soon as you see it. The problem is that two examples are not enough to know the shape of the abstraction. Watch what happens. The tanker intake screen and the lab screen both need a status chip. Two usages, so you extract to . It takes a and a . Then billing needs one with an icon. → add . Then the farmer portal needs one that is clickable. → add and a output. Then lab needs a small variant for a dense table. → add . Then dispatch needs one where the icon is on the right. → add . You now have a shared component with six inputs, thirty-two possible visual combinations, and five teams who will each break if you touch it. The duplication you removed was three lines of markup. The coupling you created is permanent. The version where you waited looks like this: three teams each write their own chip. By the third one, you can see what is genuinely common (a rounded pill with a label and a semantic colour) and what is not (icons, click behaviour, density). You extract the common part and leave the rest where it was. The Rule of Three: 1. First use — build it in the feature. Do not generalise. 2. Second use — copy it. Yes, actually copy it. Two similar things that can drift apart are cheaper than one wrong abstraction. 3. Third use — now you can see the pattern. Extract the part that is genuinely the same. The cost of a little duplication is a little duplication. The cost of a premature shared component is every team it touches, forever. Extract at 2 uses Extract at 3 uses --- --- --- Duplicated lines you avoided 6 12 Inputs on the final component 6 2 Teams blocked by a change to it 5 3 Can you tell what varies? No — guessing Yes — you have seen it…