Less如何优化CSS代码注释风格_利用Less特性保持规范.txt

六边形架构在Go中核心是划清三道依赖线：领域层禁用适配器、端口接口须定义在domain或infra、DI入口必须位于adapter层；目录隔离重于结构模板，gRPC需作为驱动适配器而非领域延伸，Wire需严查指针返回与显式绑定。六边形架构在 Go 里不是"搭架子"，而是划清三道线Go 项目用六边形架构，核心不是目录建得多整齐，而是靠三道不可逾越的依赖线把业务逻辑护住：领域层 不能 import 任何适配器（比如 github.com/go-sqlite/sqlite3、google.golang.org/grpc）、端口接口必须定义在领域层或 infra 层（不能藏在 adapter/repository 里）、Wire 或其他 DI 工具的 inject.go 文件必须落在适配器层------这是唯一能同时看到领域接口和具体实现的地方。常见错误现象：domain/order_service.go 直接 import "gorm.io/gorm"，后续加 Redis 缓存或换 PostgreSQL 就得改业务代码正确做法：在 domain/repository.go 定义 type OrderRepository interface { Save(ctx context.Context, o *Order) error }，让 adapter/repository/mysql_order_repo.go 去实现它Wire 的 InitializeApp() 函数必须放在 cmd/ 或 adapter/server/ 下，否则生成的依赖图会绕过端口约束目录结构别硬套模板，先守住 domain/ 和 adapter/ 的物理隔离很多团队卡在第一步，是因为照抄 "domain/aggregate/entity" 这类子目录，结果把 po.Order（数据库表结构）和 domain.Order（含业务规则的实体）混在同一个包里，或者让 adapter/controller 直接 new 出 domain.OrderService ------ 这等于把六边形画成了实心圆。domain/ 下只放：聚合根（order.Aggregate）、值对象（money.Money）、领域服务接口（order.PaymentService）、DTO（order.CreateOrderRequest）adapter/ 下分两块：controller/（接收 HTTP 请求、校验、转成 domain.DTO）、repository/（实现 domain.Repository 接口，用 SQL 或 gRPC 调用外部服务）infra/ 是可选缓冲区：放 infra/db/sqlx_client.go、infra/mq/kafka_producer.go 等"纯技术组件"，它们被 repository 适配器调用，但 domain 层完全看不见gRPC 服务怎么当好"驱动适配器"，而不是入侵领域层gRPC 不是领域模型的延伸，它是外部系统驱动你业务的一条通道。把它当"HTTP 的替代品"来用，就很容易把 proto 文件里的 message 直接当 domain 实体用，导致领域逻辑被 protobuf 序列化规则绑架。 Mokker AI AI产品图添加背景