A new part is a long-term commitment: it introduces a public capability, data ownership, maintenance work, and a place in assembled products. Holism should add one when a domain is coherent and useful beyond a single niche workflow. The evaluation need not become a large architecture ceremony. A short review of customers, boundaries, contracts, settings, and operations can prevent a small feature from becoming a costly shared dependency.
Name the business capability
Describe what a user can accomplish with the proposed part and where that work begins and ends. “Orders” is a clearer capability than a folder of miscellaneous checkout helpers. Identify the primary items and actions, such as creating an order, changing its state, or finding a record. If the description combines unrelated jobs, the proposed part may be too broad. If it only wraps one button, it may be too small to justify its own boundary.
Check reuse against real products
List existing or planned products that would use the capability and compare their rules. Similar vocabulary does not guarantee the same model. A restaurant order and a course enrollment can share some purchase mechanics while their fulfillment differs. Keep the shared contract to the stable portion. Product-specific rules can remain in the runnable product. A part should earn its place through actual reuse or a clear general domain, not through a speculative wish for future customers.
Define ownership and relationships
Choose which records the part owns and what other parts provide. Same-part relationships should follow the platform's relation rules; cross-part data may need complete embedded values because databases can be separated by part. Avoid depending on another part's private schema. Decide how changes in related data are reflected and what the item means when the other part is unavailable. These questions are easier to answer before multiple callers depend on the first implementation.
Design the public contract
Expose useful operations and render-ready data through the part's public API. Keep storage details and business internals private. Follow the platform's route shape and centralized ID utilities so callers do not construct identifiers or infer database structure. Define localized errors and permission requirements for each operation. A good contract lets a panel or site use the part without importing implementation files from another repository.
Identify safe variation
Determine which differences are tenant settings, item attributes, UI variants, or genuinely separate workflows. Give settings clear scopes, types, defaults, and validation. Avoid adding flags that create many untested combinations. If the part has states and transitions, define them through the dynamic state-machine system instead of freezing them in the part definition. Variation should be visible to administrators and understandable to the team maintaining it.
Estimate operating cost
A part needs migrations, localization, monitoring, documentation, and compatibility work as products evolve. Consider whether it adds a process, external provider, or data store. For SMB products, prefer the simplest design that meets the current use case and leaves a clean extension path. Identify one owner for the public contract and one critical test journey in the assembled product. Shared code without ownership can cost more than duplicated code.
Make the decision reversible where possible
Start with a focused contract and avoid promising every possible extension in version one. Record what was deliberately left outside. If the capability later proves too specific, it can stay near one product; if multiple products converge, a stable common layer can be extracted. The goal is a part that makes product delivery easier while keeping the platform understandable to the people who operate it. Before approving the new boundary, sketch one ordinary use and one failure case from a second product. If the same contract serves both without hidden exceptions, the design has a stronger basis.