Last updated April 21, 2026
For Developers
You've just been assigned a service you didn't write, in a system you've never seen, and the ticket says "add a field." Before you touch anything, you need to understand what's connected to what — and what breaks if you get it wrong. That's where ContextDX comes in.
Developer Quick Start
Get oriented fast — these are the essentials:
- Get workspace access from your architect or team lead
- Open the board for your service and explore its nodes and relationships
- Bind your GitHub repo as a source on the relevant board
- Run an impact analysis on a node you're planning to change
- Ask chat a question about your system
- Review the context map for your bounded context
Core Developer Workflows
Explore Inherited Systems
Open the board for your service and see the full picture: upstream consumers, downstream dependencies, data stores, message queues, third-party integrations. Instead of grepping through repos and piecing together a mental model, you're looking at a curated architectural view that your team's architect maintains as a living artifact.
Click any node to see its details, bound sources, and relationships. The board isn't just a picture — it's an interactive map you can drill into.
Understand Bounded Contexts
Use context maps — boards that show how bounded contexts interact (shared kernels, anti-corruption layers, published languages) — to see how your domain connects to others. When you're working at a domain boundary, this view tells you which contracts you need to respect and which team owns the other side.
If a context map feels overwhelming, filter by the context tags relevant to your team. You don't need the whole universe — just your neighborhood.