# Five Bounded Contexts in WiFi DensePose Architecture: A Domain-Driven Design Guide

> Explore the five bounded contexts in WiFi DensePose architecture Signal Pose Streaming Storage and Hardware Understand their distinct responsibilities models and implementation for independent scaling and maintenance

- Repository: [rUv/wifi-densepose](https://github.com/ruvnet/wifi-densepose)
- Tags: architecture
- Published: 2026-02-16

---

**WiFi DensePose organizes its system into five bounded contexts—Signal, Pose, Streaming, Storage, and Hardware—each with distinct responsibilities, models, and implementation files that enable independent scaling and maintenance.**

WiFi DensePose is an open-source project that applies Domain-Driven Design (DDD) principles to structure its codebase. Understanding the **five bounded contexts in WiFi DensePose architecture** is essential for developers who want to extend the system, debug issues, or deploy it in production environments. Each context maintains its own ubiquitous language and clear boundaries, preventing domain logic from leaking between subsystems.

## The Five Bounded Contexts in WiFi DensePose

The architecture is explicitly documented in [`rust-port/wifi-densepose-rs/docs/ddd/bounded-contexts.md`](https://github.com/ruvnet/wifi-densepose/blob/main/rust-port/wifi-densepose-rs/docs/ddd/bounded-contexts.md) and implemented across separate Python modules in the `v1/` directory. Each context handles a specific aspect of the WiFi sensing pipeline.

### 1. Signal Domain (CSI Processing)

The **Signal Domain** manages the acquisition and preprocessing of raw Channel State Information (CSI). This context validates incoming CSI frames, applies noise removal algorithms, and extracts signal features like amplitude, phase, and Doppler estimation.

Core concepts include **CSI Frame**, amplitude/phase processing, noise removal, and Doppler estimation. The primary implementation resides in [`v1/src/core/csi_processor.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/core/csi_processor.py).

```python

# 1️⃣ Signal: Run a CSI processing pipeline

from v1.src.core.csi_processor import CSIProcessor

config = {
    "sampling_rate": 1000,
    "window_size": 256,
    "overlap": 0.5,
    "noise_threshold": -80,
}
processor = CSIProcessor(config)

# `csi_frame` would be a CSIData instance received from hardware

result = await processor.process_csi_data(csi_frame)
print("Human detected:", result.human_detected)

```

### 2. Pose Domain (DensePose Inference)

The **Pose Domain** transforms processed CSI features into visual-like representations and performs dense-pose estimation. This context handles activity classification, key-point detection, and confidence scoring for human pose reconstruction.

Key concepts include **PoseEstimate**, **ModalityTranslation**, confidence scoring, and activity enumeration. The implementation is found in [`v1/src/models/densepose_head.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/models/densepose_head.py).

```python

# 2️⃣ Pose: Load a DensePose model configuration

from v1.src.models.densepose_head import DensePoseHead
from v1.src.config.settings import get_domain_config

domain_cfg = get_domain_config()
model_cfg = domain_cfg.pose_models["default"]
pose_model = DensePoseHead(model_cfg.model_path)

# `features` are extracted CSI features

pose = pose_model.infer(features)
print("Detected persons:", len(pose.persons))

```

### 3. Streaming Domain (WebSocket, Real-time)

The **Streaming Domain** manages live data delivery to clients via WebSocket connections. This context handles session management, subscription filters, back-pressure mechanisms, and quality-of-service (QoS) guarantees for real-time pose streaming.

Core concepts include **Session**, **StreamType**, **SubscriptionFilters**, and heartbeat mechanisms. The implementation is located in [`v1/src/api/websocket/pose_stream.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/api/websocket/pose_stream.py).

```python

# 3️⃣ Streaming: Broadcast a pose estimate to subscribed clients

from v1.src.api.websocket.connection_manager import ConnectionManager
from v1.src.api.websocket.pose_stream import PoseStreamer

conn_mgr = ConnectionManager()
streamer = PoseStreamer(conn_mgr)
await streamer.broadcast_pose(pose)  # Sends to all active WebSocket sessions

```

### 4. Storage Domain (Persistence)

The **Storage Domain** provides repositories for persisting CSI frames, pose estimates, session records, and device configurations. This context abstracts database operations, handles transactions, and manages schema migrations.

Key concepts include **Repository**, **Entity**, **Transaction**, and migration patterns. The primary definitions are in [`v1/src/database/models.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/database/models.py).

```python

# 4️⃣ Storage: Persist a CSI frame and a pose estimate

from v1.src.database.model_types import CsiFrameRepository, PoseEstimateRepository
from v1.src.database.connection import get_db

db = await get_db()
csi_repo: CsiFrameRepository = db.csi_frame_repo
pose_repo: PoseEstimateRepository = db.pose_estimate_repo

frame_id = await csi_repo.save(csi_frame)
estimate_id = await pose_repo.save(pose)
print("Saved frame", frame_id, "and estimate", estimate_id)

```

### 5. Hardware Domain (Device Management)

The **Hardware Domain** abstracts physical Wi-Fi hardware, handling device discovery, connection management, configuration, health monitoring, and calibration procedures. This context isolates vendor-specific hardware details from the signal processing logic.

Core concepts include **Device**, **DeviceType**, **Calibration**, and health monitoring. The implementation is found in [`v1/src/hardware/router_interface.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/hardware/router_interface.py).

```python

# 5️⃣ Hardware: Discover and connect to a router device

from v1.src.hardware.router_interface import RouterInterface
from v1.src.core.router_interface import RouterController

router = RouterInterface()
devices = await router.discover()
router_ctrl = RouterController(devices[0])
await router_ctrl.connect()
print("Connected to router at", router_ctrl.ip_address)

```

## Summary

The **five bounded contexts in WiFi DensePose architecture** provide a clean separation of concerns that enables independent evolution, testing, and scaling of each subsystem:

- **Signal Domain** handles raw CSI acquisition and preprocessing in [`v1/src/core/csi_processor.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/core/csi_processor.py)
- **Pose Domain** manages DensePose inference and activity classification in [`v1/src/models/densepose_head.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/models/densepose_head.py)
- **Streaming Domain** delivers real-time data via WebSocket in [`v1/src/api/websocket/pose_stream.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/api/websocket/pose_stream.py)
- **Storage Domain** persists entities and handles transactions in [`v1/src/database/models.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/database/models.py)
- **Hardware Domain** abstracts Wi-Fi device management in [`v1/src/hardware/router_interface.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/hardware/router_interface.py)

This DDD approach ensures that domain logic remains isolated within clear boundaries, preventing coupling between signal processing, machine learning inference, and infrastructure concerns.

## Frequently Asked Questions

### What is a bounded context in WiFi DensePose?

A bounded context in WiFi DensePose is a distinct subsystem with its own ubiquitous language, models, and responsibilities that isolates specific domain logic. According to the source code in [`rust-port/wifi-densepose-rs/docs/ddd/bounded-contexts.md`](https://github.com/ruvnet/wifi-densepose/blob/main/rust-port/wifi-densepose-rs/docs/ddd/bounded-contexts.md), these boundaries prevent technical concepts from leaking between signal processing, pose estimation, and hardware management layers.

### How does the Signal Domain interact with the Pose Domain?

The Signal Domain processes raw Channel State Information and extracts features that serve as input to the Pose Domain's DensePose inference models. This interaction follows a pipeline pattern where `CSIProcessor` in [`v1/src/core/csi_processor.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/core/csi_processor.py) outputs structured features that `DensePoseHead` in [`v1/src/models/densepose_head.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/models/densepose_head.py) consumes for human pose estimation.

### Why is the Hardware Domain separated from the Signal Domain?

The Hardware Domain is separated to isolate vendor-specific Wi-Fi device implementations from the signal processing algorithms, allowing the system to support multiple router types without modifying CSI processing logic. This boundary, implemented in [`v1/src/hardware/router_interface.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/hardware/router_interface.py), ensures that device discovery, calibration, and health monitoring concerns remain independent from the mathematical operations performed in [`v1/src/core/csi_processor.py`](https://github.com/ruvnet/wifi-densepose/blob/main/v1/src/core/csi_processor.py).

### Where are the bounded contexts documented in the repository?

The five bounded contexts are formally documented in [`rust-port/wifi-densepose-rs/docs/ddd/bounded-contexts.md`](https://github.com/ruvnet/wifi-densepose/blob/main/rust-port/wifi-densepose-rs/docs/ddd/bounded-contexts.md), which defines the ubiquitous language, responsibilities, and relationships for each context. The actual implementations are found in the `v1/src/` directory, with specific modules like [`core/csi_processor.py`](https://github.com/ruvnet/wifi-densepose/blob/main/core/csi_processor.py), [`models/densepose_head.py`](https://github.com/ruvnet/wifi-densepose/blob/main/models/densepose_head.py), and [`hardware/router_interface.py`](https://github.com/ruvnet/wifi-densepose/blob/main/hardware/router_interface.py) corresponding to their respective domains.