A cross-repository import can look like a quick way to reuse a helper. In a composed platform, importing another part's private file makes the caller depend on layout, build output, and implementation details that were never promised as an interface. The immediate code may be shorter, but future changes become harder to coordinate. Understanding that cost helps teams reuse behavior through stable public boundaries instead.
Hidden coupling in a path
A deep path such as a part's internal business folder tells the consumer where code happens to live today. Renaming a file, splitting a module, or changing its dependencies may break an unrelated product. The provider cannot tell which internals are safe to refactor because consumers may reach anywhere. A public bundle or alias gives the provider a smaller set of contracts to maintain. It also lets code review distinguish an intentional dependency from an accidental one. Directory structure is an implementation detail; a public operation should be the promise.
Bundling and deployment effects
Software Product Lines often build a core bundle and a separate bundle for each part. A private import can cause one part to pull another part's internals into its bundle, defeating that separation. The problem may not appear in local tests because both repositories are mapped into the same development directory. It can surface during production builds, independent upgrades, or a deployment that excludes an optional part. A consumer should depend on a part's public interface so the build graph reflects the intended product graph. Inspect the generated bundle when a new dependency is introduced.
Security and business rule drift
Bypassing a public operation can also bypass validation, authorization, or tenant scoping that the owning part applies at its boundary. A helper that returns raw documents may not enforce the same policy as the official read action. The consumer may add its own filter and later miss a change in the owner's rules. This is especially risky for cross-tenant data and customer-specific configuration. Public operations should state what they guarantee, including permissions and data freshness. Direct database or internal-module access makes those guarantees hard to audit.
Distinguish reuse from ownership
If several parts need a domain-neutral rule, move it to the appropriate core rather than importing it from whichever part implemented it first. If the behavior belongs to one domain, expose a focused public operation from that part. If an integration combines domains, create a coordinating operation at the product boundary. Avoid moving niche behavior into core merely to satisfy an import rule; that turns one dependency problem into a platform design problem. The goal is a dependency graph whose direction matches ownership.
Migrating existing deep imports
Inventory references to private paths, group them by the capability they use, and define a public contract for each genuine cross-part need. Update consumers in small changes and verify the composed product. Remove private exports that are no longer needed. Contract tests can preserve observable behavior while the provider reorganizes internally. Some calls may reveal that data was duplicated or a business rule has no clear owner; resolve that explicitly rather than disguising it behind a new barrel file that merely re-exports internals.
Pay for clarity once
A public interface can require a little more design up front. That effort buys safer refactoring, clearer ownership, independent bundling, and easier onboarding. For a small team maintaining several products, those benefits accumulate quickly. The cost of a deep import is rarely the line of code itself. It is the uncertainty imposed on every future change to the provider. A stable boundary turns reuse into a deliberate relationship that the team can test and evolve. It also makes dependency reviews simpler: a consumer states the capability it needs, and the provider can decide whether the public interface should offer it.