Aviation Frontend Construction Log: Structuring with Folder Name Prefix Symbols Instead of FSD

This is the final installment of the Aviation Frontend Construction Log series, introducing a case where the team held off on adopting FSD (Feature-Sliced Design) and instead applied folder name prefix symbol rules. Previously, it was difficult to determine the impact scope (popup-only, full-screen, shared) based solely on file names, making reference checks cumbersome during deletion and leading to frequent duplicate files.

Folder Name Prefix Symbol Rules

Due to a lack of team consensus and schedule pressure, the team held off on adopting FSD and instead applied a three-tier prefix symbol rule.

• shared/: Files shared across the entire project
• _name/: Shared by multiple files within the same layer
• +name/: Exclusive to the file with the symbol removed (paired folder)

+ prefix folders cannot be imported from outside, so the dependency direction is automatically determined. This allows deleting the entire folder when removing a file, eliminating the need for reference searches. This rule is applied recursively, meaning the meaning of the symbols remains consistent regardless of depth.

Structural Characteristics and Limitations

Through prefix structures such as _hooks, _ui, _widget, _server, and _types within screens, the folder structures for domestic and international routes are kept symmetrical. The criterion for determining sharing scope is 'who uses it': if only you use it, use +; if multiple files in the layer use it, use _; if it is shared across the whole project, use shared, thereby reducing ambiguity in judgment.

However, name-based pairing cannot be verified via imports or linting, so changing a file name without updating the folder name can break the pairing. Two out of 39 cases had mismatches, but automated mechanical verification has not been implemented. There is no comparison of superiority over FSD; the key feature is reducing the learning burden by shrinking from 6 layers to 2 symbols.