summaryrefslogtreecommitdiff
path: root/2025/03/20/TDD-和-DDD-的一些小想法/index.html
diff options
context:
space:
mode:
Diffstat (limited to '2025/03/20/TDD-和-DDD-的一些小想法/index.html')
-rw-r--r--2025/03/20/TDD-和-DDD-的一些小想法/index.html14
1 files changed, 10 insertions, 4 deletions
diff --git a/2025/03/20/TDD-和-DDD-的一些小想法/index.html b/2025/03/20/TDD-和-DDD-的一些小想法/index.html
index 8c1575ec..e7adc5c0 100644
--- a/2025/03/20/TDD-和-DDD-的一些小想法/index.html
+++ b/2025/03/20/TDD-和-DDD-的一些小想法/index.html
@@ -193,25 +193,31 @@
</div>
<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>
+<h3 id="Test-Driven-Development-TDD"><a class="header-anchor" href="#Test-Driven-Development-TDD">¶</a>Test-Driven Development (TDD)</h3>
+<h4 id="优点:"><a class="header-anchor" href="#优点:">¶</a>优点:</h4>
+<ol>
<li>提高代码质量:通过编写测试来驱动开发,可以确保代码的正确性和可靠性。</li>
<li>减少缺陷:早期发现和修复缺陷,减少后期的调试和维护成本。</li>
<li>促进可维护性:代码更加模块化和可测试,便于后续的维护和扩展。</li>
<li>文档化:测试代码本身就是一种文档,描述了系统的行为和期望。</li>
<li>提高开发速度:虽然初期可能会慢一些,但长期来看,由于减少了重构和调试的时间,开发速度会提高。</li>
</ol>
-<h4 id="缺点:"><a href="#缺点:" class="headerlink" title="缺点:"></a>缺点:</h4><ol>
+<h4 id="缺点:"><a class="header-anchor" href="#缺点:">¶</a>缺点:</h4>
+<ol>
<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>
+<h3 id="Domain-Driven-Design-DDD"><a class="header-anchor" href="#Domain-Driven-Design-DDD">¶</a>Domain-Driven Design (DDD)</h3>
+<h4 id="优点:-v2"><a class="header-anchor" href="#优点:-v2">¶</a>优点:</h4>
+<ol>
<li>聚焦领域:通过深入理解业务领域,确保软件系统与业务需求紧密结合。</li>
<li>模型驱动:建立一个清晰的领域模型,帮助开发者和业务专家共同理解系统。</li>
<li>可维护性:通过明确的领域模型和边界,系统结构更加清晰,便于维护和扩展。</li>
<li>沟通桥梁:提供了一种通用的语言(Ubiquitous Language),促进开发团队和业务团队之间的沟通。</li>
</ol>
-<h4 id="缺点:-1"><a href="#缺点:-1" class="headerlink" title="缺点:"></a>缺点:</h4><ol>
+<h4 id="缺点:-v2"><a class="header-anchor" href="#缺点:-v2">¶</a>缺点:</h4>
+<ol>
<li>复杂性高:DDD方法论较为复杂,需要深入理解领域模型和设计模式。</li>
<li>初期投入大:需要大量的时间和精力进行领域分析和建模。</li>
<li>适用范围有限:对于简单的系统或小型项目,DDD可能显得过于复杂和冗余。</li>