English | 한국어
시스템 목차 | 이전: Source layout | 다음: 설계 결정
Core POSD module structure¶
이 장이 정의하는 것 — Core 소스를 POSD 원칙에 따라 계층과 module로 나누는 기준과 각 계층의 책임 경계.
1. 목표¶
좁은 공개 interface 뒤에 구현 복잡성을 숨기는 깊은 module을 만드는 설계 원칙을 POSD(A Philosophy of Software Design)라 한다. Core는 이 원칙에 따라 좁은 raw socket(message를 주고받는 endpoint) C ABI 뒤에 transport, connection, pipe와 protocol 복잡성을 숨긴다. Application service 의미를 Core helper나 option으로 다시 노출하지 않는다.
계약 소유 — 이 문서 전체는 계약 서술이 아니라 구현 서술이다. 여기 적힌 계층 구조가 코드와 다르면 문서를 코드에 맞춘다. Core가 application에 보장하는 공개 동작은 아래 표의 문서들이 소유하며, 이 문서는 그 계약을 다시 정의하지 않는다.
| 관련 계약 | 정의하는 문서 |
|---|---|
| 디렉터리 배치와 include 방향 | Core source layout |
| Context 생성·옵션·종료 | Context |
| message lifecycle와 ownership | Message |
| socket 생성·옵션·송수신 | Socket 공통 |
2. 계층별 책임¶
Core 소스는 다음 다섯 계층으로 나뉜다. 각 계층은 자기 행의 책임만 소유한다.
| 계층 | 책임 |
|---|---|
| Public C API와 API integration | argument·handle·ownership·C API result 변환과 public multipart·request correlation·completion state를 관리한다 |
| Socket semantics | socket type별 routing과 pipe 선택·전달을 관리하고 API integration의 request/reply state와 연결한다 |
| Runtime core | context, session, pipe와 mailbox command를 다루고 lifecycle을 관리한다 |
| Engine | ZMP·RAW framing과 handshake를 수행한다 |
| Transport | TCP, WebSocket, IPC, inproc과 TLS로 I/O를 수행한다 |
경계는 양방향으로 지킨다. Public API가 transport type이나 protocol parser를 직접 분기하지 않는다. Runtime core는 socket type별 정책을 알지 않으며, engine은 application payload 의미를 해석하지 않는다. 각 계층이 어느 디렉터리에 있고 include 방향을 어떻게 제한하는지는 Core source layout이 서술한다.
3. 위험 신호¶
다음 신호는 위 계층 경계가 무너지고 있다는 뜻이다. Framework는 Core 위에서 application service를 제공하는 상위 계층이다.
- Framework service 개념이 public Core type이나 option으로 추가된다.
- API facade가 인자를 그대로 전달하는 service-specific pass-through가 된다.
- 동일한 protocol field를 여러 engine이나 binding에서 수동으로 정의한다.
- Socket semantics가 application callback이나 Framework helper로 밀려난다.
- Framework가 private Core header나 symbol을 직접 사용한다.
이 신호가 나타나면 새 helper를 추가하기 전에 책임 경계를 다시 검토한다.