Quick Comparison

Manager, System, Service는 Unity의 특별한 base type이 아닙니다. 팀이 같은 호출 방향과 ownership을 기대하도록 이름을 쓰는 convention입니다. 이름보다 API, state owner, lifecycle이 역할과 맞는지가 우선입니다.

BattleFlowManager
  -> CombatSystem.ResolveTurn(command)
  -> RewardService.Grant(reward)
  -> BattlePresenter.Show(result)

CombatSystem은 reward UI를 직접 열지 않고,
RewardService는 battle phase를 직접 바꾸지 않는다.

이름을 고르는 기준

BattleFlowManager는 turn start, pause, finish처럼 여러 participant의 순서를 조정할 때 자연스럽습니다. damage formula, cooldown validation, target rule처럼 입력을 받아 domain 규칙을 적용하는 것은 CombatSystem에 가깝습니다. save serialization, localization lookup, remote config처럼 여러 consumer에게 안정적인 capability를 제공하는 것은 SaveService·LocalizationService에 가깝습니다.

어느 역할도 절대 규칙은 아닙니다. ECS의 System은 component set을 반복 처리할 수 있고, 작은 project의 manager는 service 역할을 겸할 수 있습니다. 중요한 것은 같은 이름의 object가 팀 안에서 비슷한 lifecycle·dependency direction·side effect 범위를 유지하는 것입니다. 이름과 실제 책임이 어긋나면 rename보다 분리가 먼저일 수 있습니다.

호출 방향과 lifecycle

manager가 system 내부 collection을 직접 편집하거나, system이 UI manager를 직접 호출하면 flow와 rule이 섞입니다. manager는 command/result를 통해 rule을 조정하고, system은 event/result로 state change를 알립니다. service가 stateful session을 소유한다면 app·mode·scene 중 scope와 dispose owner도 이름 옆에 드러나야 합니다.

Unity MonoBehaviour가 붙었다고 manager가 되는 것은 아닙니다. Update와 scene reference가 필요한 coordinator는 component일 수 있지만, pure rule system과 save service는 plain C# object가 test하기 쉬운 경우가 많습니다. 어떤 타입이 DontDestroyOnLoad에 살아야 하는지도 이름이 아니라 실제 scope로 결정합니다.

구조를 점검하기

한 object가 UI, storage, domain rule, scene loading을 모두 호출하면 Manager라는 이름이 구조를 가릴 수 있습니다. 새 기능 하나를 추가할 때 flow만 바뀌는지, rule만 바뀌는지, shared capability만 바뀌는지 보고 각각 다른 object를 수정하게 되는지 확인합니다.