どっちの内部設計方針をとったとしても、ユーザから見える振る舞いは変わらないので、正味どちらでも良い。でも、どちらの方針を取るか決めなければならい、どうしよう？ そんな岐路に立たされたこと、あると思います。
振る舞い上はどちらでも良い
例えばRailsであれば、
- ユーザ種別毎にnamespaceでURLを切るべきか？ それともURLではなく、内部のロジックで権限制御するか？
- ユーザのテーブルを種別毎に用意するか？ それとも単一テーブル継承で種別毎にクラスをつくるか？
といったような設計判断は、たびたびあると思います。
振る舞いとしてはどちらも同じだけれども、今後の開発を考えると、どちらがベストなのか？ という問題です。方針を誤るとロジックに無理が出てきて不具合を生みやすくなったり、そのためテストも複雑化して保守性に悪い影響をもたらします。
制約を探す
ありきたりな答えになりますが、「こっちの設計の方がベスト！」と言える制約をきっちり探して、設計に納得感を持って開発を進めるのが良いと思います。
今後の開発を見据えると、ユーザ種別毎に全く異なる機能を提供することになる、ということであればnamespaceで切る方が妥当だろう、といった具合です。
現時点で全く開発の方向性がはっきりしない場合は、むしろ良い機会だと考えて、方向性を決めてしまうのも手です。今後の方向性がきちんと共有できていると、設計する側も将来的な制約を意識しながら設計ができるため、結果として良い設計に結びつきやすいです。その場その場で単にチケットの要件を満たすだけの設計をしていると、論理的な破綻が起きやすいと思います。
結論としては「どっちでも良い、ということがないように設計するのが良い」という話でした。