1 files changed, 15 insertions, 15 deletions
diff --git a/2025/03/20/TDD-和-DDD-的一些小想法/index.html b/2025/03/20/TDD-和-DDD-的一些小想法/index.html
index e1b89568..a05a3f92 100644
--- a/2025/03/20/TDD-和-DDD-的一些小想法/index.html
+++ b/2025/03/20/TDD-和-DDD-的一些小想法/index.html
@@ -194,27 +194,27 @@
     <div class="post-content">
     <p>Test-Driven Development (TDD) 和 Domain-Driven Design (DDD) 是两种不同的软件开发方法论，各自有其独特的优缺点和应用场景。</p>
 <h3 id="Test-Driven-Development-TDD"><a href="#Test-Driven-Development-TDD" class="headerlink" title="Test-Driven Development (TDD)"></a>Test-Driven Development (TDD)</h3><h4 id="优点："><a href="#优点：" class="headerlink" title="优点："></a>优点：</h4><ol>
-<li><strong>提高代码质量</strong>：通过编写测试来驱动开发，可以确保代码的正确性和可靠性。</li>
-<li><strong>减少缺陷</strong>：早期发现和修复缺陷，减少后期的调试和维护成本。</li>
-<li><strong>促进可维护性</strong>：代码更加模块化和可测试，便于后续的维护和扩展。</li>
-<li><strong>文档化</strong>：测试代码本身就是一种文档，描述了系统的行为和期望。</li>
-<li><strong>提高开发速度</strong>：虽然初期可能会慢一些，但长期来看，由于减少了重构和调试的时间，开发速度会提高。</li>
+<li>提高代码质量：通过编写测试来驱动开发，可以确保代码的正确性和可靠性。</li>
+<li>减少缺陷：早期发现和修复缺陷，减少后期的调试和维护成本。</li>
+<li>促进可维护性：代码更加模块化和可测试，便于后续的维护和扩展。</li>
+<li>文档化：测试代码本身就是一种文档，描述了系统的行为和期望。</li>
+<li>提高开发速度：虽然初期可能会慢一些，但长期来看，由于减少了重构和调试的时间，开发速度会提高。</li>
 </ol>
 <h4 id="缺点："><a href="#缺点：" class="headerlink" title="缺点："></a>缺点：</h4><ol>
-<li><strong>初期投入大</strong>：需要在开发前编写测试，初期投入的时间和精力较大。</li>
-<li><strong>学习曲线陡峭</strong>：对新手开发者来说，学习和掌握TDD需要一定的时间。</li>
-<li><strong>过度依赖测试</strong>：可能导致过度依赖单元测试，忽略了系统的整体性能和用户体验。</li>
+<li>初期投入大：需要在开发前编写测试，初期投入的时间和精力较大。</li>
+<li>学习曲线陡峭：对新手开发者来说，学习和掌握TDD需要一定的时间。</li>
+<li>过度依赖测试：可能导致过度依赖单元测试，忽略了系统的整体性能和用户体验。</li>
 </ol>
 <h3 id="Domain-Driven-Design-DDD"><a href="#Domain-Driven-Design-DDD" class="headerlink" title="Domain-Driven Design (DDD)"></a>Domain-Driven Design (DDD)</h3><h4 id="优点：-1"><a href="#优点：-1" class="headerlink" title="优点："></a>优点：</h4><ol>
-<li><strong>聚焦领域</strong>：通过深入理解业务领域，确保软件系统与业务需求紧密结合。</li>
-<li><strong>模型驱动</strong>：建立一个清晰的领域模型，帮助开发者和业务专家共同理解系统。</li>
-<li><strong>可维护性</strong>：通过明确的领域模型和边界，系统结构更加清晰，便于维护和扩展。</li>
-<li><strong>沟通桥梁</strong>：提供了一种通用的语言（Ubiquitous Language），促进开发团队和业务团队之间的沟通。</li>
+<li>聚焦领域：通过深入理解业务领域，确保软件系统与业务需求紧密结合。</li>
+<li>模型驱动：建立一个清晰的领域模型，帮助开发者和业务专家共同理解系统。</li>
+<li>可维护性：通过明确的领域模型和边界，系统结构更加清晰，便于维护和扩展。</li>
+<li>沟通桥梁：提供了一种通用的语言（Ubiquitous Language），促进开发团队和业务团队之间的沟通。</li>
 </ol>
 <h4 id="缺点：-1"><a href="#缺点：-1" class="headerlink" title="缺点："></a>缺点：</h4><ol>
-<li><strong>复杂性高</strong>：DDD方法论较为复杂，需要深入理解领域模型和设计模式。</li>
-<li><strong>初期投入大</strong>：需要大量的时间和精力进行领域分析和建模。</li>
-<li><strong>适用范围有限</strong>：对于简单的系统或小型项目，DDD可能显得过于复杂和冗余。</li>
+<li>复杂性高：DDD方法论较为复杂，需要深入理解领域模型和设计模式。</li>
+<li>初期投入大：需要大量的时间和精力进行领域分析和建模。</li>
+<li>适用范围有限：对于简单的系统或小型项目，DDD可能显得过于复杂和冗余。</li>
 </ol>
 <hr>
 <p>TDD 和 DDD 并不冲突，实际上它们可以互补。TDD 可以帮助确保代码的正确性和可靠性，而 DDD 可以确保系统与业务需求紧密结合。在进行 TDD 时，可以使用 DDD 的领域模型和 Ubiquitous Language 来编写测试用例，确保测试覆盖了业务需求。在进行 DDD 时，可以使用 TDD 来驱动实现，确保每个领域模型的实现。</p>