Sublime Text 不支持 DDD 建模，仅能通过文件夹结构显式划分限界上下文、插件辅助导航、命名/注释强化边界、手绘上下文映射图等方式支持 DDD 实践。
Sublime Text 本身不提供领域驱动设计（DDD）的建模或架构支持，它只是一个轻量级代码编辑器。在 Java 或 C# 项目中实践 DDD、划分限界上下文（Bounded Context），核心依赖的是团队对 DDD 的理解、项目结构设计、模块拆分策略和协作规范，而不是编辑器功能。Sublime 可以辅助这一过程，但需配合合理的工作流和插件增强可读性与导航效率。
用文件夹结构显式表达限界上下文
限界上下文不是代码里的类或注解，而是团队约定的语义边界。最直接的方式是在项目根目录下按上下文命名划分顶层包/命名空间目录：
- Java 项目示例：
src/main/java/com/example/ordering/（订单上下文）、src/main/java/com/example/inventory/（库存上下文） - C# 项目示例：解决方案中建立独立项目
MyApp.Ordering.Domain、MyApp.Inventory.Application - 每个上下文内自包含领域模型、应用服务、仓储接口——避免跨上下文直接引用实体或值对象
借助 Sublime 插件提升上下文内导航效率
虽然 Sublime 不具备 IDE 级别的语义分析能力，但可通过以下插件辅助 DDD 实践：
- SideBarEnhancements：快速复制路径、打开终端到当前上下文根目录，便于执行上下文级构建或测试
-
ProjectManager：为每个限界上下文保存独立项目配置，切换上下文即切换工作集（如只显示
ordering/相关文件） - CTags + SublimeCodeIntel（谨慎启用）：在单个上下文内跳转类/方法，减少误触其他上下文实现
用命名与注释强化上下文边界意识
在缺乏编译期强制隔离的场景下（如单体 Java 模块未物理拆分），需靠约定降低认知负担：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 所有领域类名带上上下文前缀或后缀，例如
OrderingService、InventoryItem，而非泛化的Service或Item - 在 package-info.java 或命名空间注释中声明该上下文的通用语言（Ubiquitous Language）关键词，例如：
“本上下文中的‘Order’指代客户发起的采购请求，不含物流履约状态” - 关键防腐层（Anti-Corruption Layer）实现类命名体现转换意图，如
InventoryItemToOrderingProductAdapter
定期做上下文映射草图，别只盯代码
限界上下文关系（合作关系、客户-供应商、遵奉者等）无法从 Sublime 中自动推导。建议：
- 用 PlantUML 或 Excalidraw 绘制上下文映射图（Context Map），贴在团队共享文档里
- 每次新增集成点（如调用外部库存 API），同步更新映射图并评审是否需要新上下文或 ACL
- 在 Sublime 中用
TODO: [CONTEXT-MAP]标记跨上下文调用点，作为评审线索
基本上就这些。DDD 的成败不在工具，而在是否让每个上下文有清晰的职责、语言和演进节奏。Sublime 能帮你更清爽地看见结构、更快地聚焦边界——前提是结构本身已被想清楚。
