Category
Preparing references and filters for this topic. 이 주제의 레퍼런스와 필터를 준비하고 있습니다.
Category Reference
manager, system, service, ownership, event 흐름 같은 설계 판단을 카드형 레퍼런스로 정리합니다.
Search titles, summaries, tags, and subcategories.
Showing 9 cards.
Subcategory
9 cards
매니저, 시스템, 서비스라는 이름을 언제 쓰고 어떤 책임 경계를 기대해야 하는지 설계 판단 관점에서 정리합니다.
Manager
-> 조정과 orchestration
System
-> 규칙 실행과 처리 파이프라인
Service
-> 재사용 가능한 기능 제공어떤 데이터와 규칙을 어느 서비스가 소유해야 하는지, 그리고 경계를 넘는 책임을 어떻게 줄일지 설계 판단 관점에서 정리합니다.
한 서비스가 소유해야 할 것
-> 자기 데이터
-> 자기 규칙
-> 자기 상태 변화
남의 데이터까지 직접 고치기 시작
-> 경계가 흐려짐서비스와 시스템을 연결할 때 event-driven 구조가 맞는지, 아니면 직접 호출이 더 단순한지 판단 기준 중심으로 정리합니다.
한 결과를 여러 곳이 들어야 함
-> event
순서와 성공 여부가 중요함
-> direct call객체 조립을 어디서 끝내고 런타임 흐름 시작을 어디서 넘길지, composition root와 bootstrap 경계를 설계 판단 관점에서 정리합니다.
Composition Root
-> 의존성 조립이 끝나는 곳
Bootstrap
-> 앱/게임 시작 순서를 여는 곳
둘을 섞으면
-> 초기화 순서와 wiring이 같이 꼬임에디터에서 만드는 데이터와 플레이 중 바뀌는 상태를 어디서 분리해야 하는지 설계 판단 관점에서 정리합니다.
Authoring Data
-> 디자이너가 만든 원본 설정
Runtime State
-> 플레이 중 변하는 값
원본과 상태를 같이 들고 다니면
-> 저장/리셋/복제가 꼬임씬이 바뀔 때 어떤 의존성을 씬 내부에서 조립하고 어떤 것은 상위 루트에서 넘길지 Scene DI 경계를 설계 판단 관점에서 정리합니다.
씬 안에서만 쓰는 것
-> scene scope
여러 씬이 공유하는 것
-> app/root scope
씬 로딩 때마다 전역 resolve 남발
-> 경계가 흐려짐매니저가 언제 생성되고 언제 해제돼야 하는지, 종료 책임을 어디까지 가져가야 하는지 설계 판단 관점에서 정리합니다.
Manager가 오래 산다고
-> 전역이어야 하는 것은 아님
생성 시점
-> scope 기준
해제 시점
-> owner 기준게임 시작 이후에도 모드 전환이나 feature loading 시점에 조립 지점이 필요한 경우, runtime composition root를 어디까지 둘지 설계 판단 관점에서 정리합니다.
초기 composition root
-> 앱 시작 조립
Runtime composition root
-> 모드/feature 진입 시 재조립
아무 곳에서 resolve
-> root가 사라짐이벤트 이름과 payload를 어디까지 구체적으로 설계해야 하는지, broad event와 narrow contract 사이 경계를 설계 판단 관점에서 정리합니다.
이벤트 이름
-> 무슨 일이 끝났는지 말해야 함
payload
-> 수신자가 실제로 필요한 만큼만
generic event 하나
-> 결국 분기와 캐스팅 증가