DDD 分层实战：DTO + HTML 获取逻辑应该放哪？

✨ 这个问题 80% 的开发都搞错了（含青岛软件开发常见场景）

在青岛软件开发、青岛网站制作的项目交付过程中，我们经常遇到这样的需求：

• 抓取页面 HTML
• 解析模板结构
• 构建 DTO 返回前端
• 生成模板列表/详情

很多项目正是因为这个逻辑放错层，导致架构越来越混乱。

这篇文章用最清晰的方式告诉你：
DTO + HTML 获取逻辑到底放 Domain 还是 Application？

🔍 1. 这是“业务逻辑”吗？

在实际的青岛软件开发项目里，不少同学会把 HTML 解析 + DTO 构建放进 Domain。
但让我们从 DDD 的标准来看：

• 是否包含业务规则？❌
• 是否改变领域状态？❌
• 是否需要被领域模型复用？❌

它做的是：

• 请求外部数据（I/O）
• HTML 解析
• 数据结构转 DTO

这完全是 应用编排逻辑（Application Orchestration）。
不是业务规则，不属于 Domain。

🖼️ 示意图：DTO + HTML 处理，本质是应用层职责

🧠 2. 为什么不能放 Domain？

结合青岛本地软件定制项目，主要有 3 大原因：

❌ 原因 1：Domain 必须保持纯净，不允许依赖外部世界

Domain 不能涉及：

• HTML 抓取
• HTTP 请求
• 数据转换
• 任何基础设施依赖

放进 Domain === 架构污染。

❌ 原因 2：DTO 是 Application 概念，不是 Domain 模型

DTO 是：

面向前端 / API 输出的结构，不属于领域知识

Domain 不应该根据前端需求改变模型。

❌ 原因 3：HTML 解析不会成为可复用的领域行为

它只是对外部页面的一种转换，不是：

• 业务规则
• 领域决策
• 聚合根行为

更不应该放到 Domain。

🖼️ 示意图：DTO 只属于应用层，不属于领域层

✅ 3. 正确位置：Application 层（并封装成私有方法）

在青岛软件开发项目的落地实践里，最佳做法是：

应用层负责：

• 调接口
• 获取 HTML
• 解析数据
• 组装 DTO

Domain 保持纯净，仅负责业务规则。

🔥 实战示例代码

public async Task<Result<TemplateDto>> GetTemplateAsync(int page, int size)
{
    var html = await _http.GetTemplateHtmlAsync(page, size);
 
    // ✔ 私有方法封装
    var dto = ParseTemplateHtml(html);
 
    return Result.Success(dto);
}
 
private TemplateDto ParseTemplateHtml(string html)
{
    // HTML → 对象的转换逻辑
}

🛡 4. Domain 负责“规则”，Application 负责“编排”

一句话总结：

DTO + HTML 获取逻辑不是业务，是编排。 编排属于 Application，业务属于 Domain。

这是青岛网站制作、青岛软件开发项目中最容易出错的架构点。

🖼️ 示意图总结：职责边界（Domain vs Application）

📌 5. 总结（适用于青岛软件开发 & 网站制作项目）

最终结论：

✅ 构建 DTO + 获取 HTML → 必须放 Application 层

✅ 最佳实践：封装成 Application 内部的私有方法

⭐ 想获取完整的 .NET DDD 项目源码？

专为 青岛软件开发、青岛网站制作、企业级系统重构 准备的架构模板：

• 耦合度极低
• 分层清晰
• 支持模块化
• 支持微服务扩展
• 配套示例：Redis / Hangfire / Templates / HttpClient

👇 关注我，获取 .NET DDD 源码！