고객이 주문 하나를 넣기까지, 왜 frontend 저장소와 backend 저장소와 모바일 프로젝트와 인프라 차트가 따로 필요할까요? Akan은 그 대신 동작에서 출발합니다. 고객이 화면을 보고, 액션을 수행하면, 비즈니스 규칙이 무엇이 일어나야 하는지 결정하고, 데이터가 바뀌며, 다른 클라이언트에 알림이 갈 수 있고, 같은 앱이 web, mobile, cloud, edge로 패키징됩니다.

이 페이지는 지도이지 영토가 아닙니다. 아래의 각 영역은 서로 다른 종류의 결정을 담당하고, 그 결정들이 제자리에 있는 한 제품 구조는 읽히는 상태로 남습니다. 모든 영역에 공통으로 적용되는 규칙은 세 가지입니다:

Akan은 화면이 하나뿐인 제품보다 표면이 여럿인 제품을 위해 설계되었습니다. 스토어 고객 페이지, 관리자 콘솔, 파트너 클라이언트, 모바일 앱, 엣지 장비 워크플로우는 서로 다른 인터페이스를 보여주면서 같은 규칙과 같은 데이터를 공유합니다.

거의 모든 Akan 기능은 인터페이스와 비즈니스 service 사이의 대화 하나입니다. 인터페이스는 유용한 콘텐츠를 보여주고 의도를 수집하며, 비즈니스 service는 안전한 요청을 받아 규칙을 판단하고 데이터를 바꾸며, 필요하면 백그라운드나 실시간 후속 작업을 일으킵니다.

첫 화면을 빠르게 띄우는 것은 SSR이고, 입력·클릭·필터·채팅·지도·카메라·로컬 상태는 client component가 이어받습니다. st는 응답이 도착할 클라이언트 상태를 들고, Model namespace는 모델 사용을 타입으로 묶으며, usePage는 서버와 클라이언트 양쪽에서 i18n을 해결합니다. 이 대화가 실제로 어디서 실행되는지 — 프로세스 하나인지, cloud cluster인지, edge 노드인지, mobile package인지 — 는 runtime과 infra의 결정이지 위 코드의 변경이 아닙니다.

세부 아키텍처 문서는 각 영역을 더 깊게 설명합니다. 이 overview는 지도를 작게 유지합니다. 각 영역은 서로 다른 종류의 결정을 담당하고, 그 결정들이 올바른 위치에 있을 때 제품 구조가 명확해집니다.

무언가를 만들기 전에 모든 아키텍처 문서를 먼저 읽을 필요는 없습니다. 지금 마주한 결정에서 시작해, 그 결정을 담당하는 페이지로 가면 됩니다.