From d583a9dc930ba250135ca795c5207f8343ba7411 Mon Sep 17 00:00:00 2001 From: muqiuhan Date: Thu, 20 Mar 2025 10:09:58 +0000 Subject: deploy: 951ed14c0cac247fa7f1e571c9fe27442d10dd26 --- search.xml | 190 ++++++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 131 insertions(+), 59 deletions(-) (limited to 'search.xml') diff --git a/search.xml b/search.xml index e948c62a..eae9967c 100644 --- a/search.xml +++ b/search.xml @@ -155,7 +155,6 @@ ]]> Technique - F# Archive @@ -189,7 +188,6 @@ ]]> Technique - Compilation @@ -304,7 +302,6 @@ Technique Archive - OCaml @@ -500,10 +497,36 @@ ]]> Technique - F# Archive + + DDD 中的 Ubiquitous Language + /2025/03/14/DDD-%E4%B8%AD%E7%9A%84-Ubiquitous-Languages/ + Ubiquitous Language（通用语言）是 Domain-Driven Design (DDD) 中的一个核心概念。它是一种共享的、统一的语言，用于描述和讨论领域模型中的概念和规则。Ubiquitous Language 的目的是确保开发团队和业务专家之间的沟通更加高效和准确，从而减少误解和错误。

+

一般来说，Ubiquitous Language 有以下特点：

+
    +
  1. 共享：Ubiquitous Language 是由开发团队和业务专家共同创建和使用的。它不仅用于代码和文档，还用于日常的沟通和讨论。
    2. +
  2. 统一：在整个项目中，Ubiquitous Language 应该是一致的。无论是在代码、文档、会议还是白板上，都应该使用相同的术语和概念。
    3. +
  3. 精确：Ubiquitous Language 应该尽可能精确，避免模糊和歧义。每个术语都应该有明确的定义和含义。
    4. +
  4. 演进：Ubiquitous Language 是动态的，会随着项目的进展和业务需求的变化而演进。团队应该定期审查和更新它。
    5. +
+

基于此，它可以用在这些地方：

+
    +
  1. 命名：在代码中使用 Ubiquitous Language 来命名类、方法、变量等。例如，如果业务专家使用“订单”来描述一个概念，那么在代码中也应该使用“Order”而不是“Purchase”或“Transaction”。
    2. +
  2. 文档：在文档中使用 Ubiquitous Language 来描述系统的设计、架构和功能。这有助于业务专家更容易理解技术文档。
    3. +
  3. 沟通：在团队会议、讨论和白板会议中使用 Ubiquitous Language。这有助于确保所有参与者都在讨论同一个概念。
    4. +
  4. 测试：在编写测试用例时，使用 Ubiquitous Language 来描述测试的前提条件、步骤和预期结果。这有助于确保测试覆盖了业务需求。
    5. +
+

假设正在开发一个电子商务系统，业务专家使用“订单”来描述用户购买的商品集合。团队可以在代码中使用“Order”来命名相关的类和方法：

+
type Order = {
    items: OrderItem list
    customer: Customer
    orderDate: DateTime
}

type OrderItem = {
    product: Product
    quantity: int
}

type Customer = {
    name: string
}

type Product = {
    name: string
    price: float
}

let addItem (order: Order) (item: OrderItem) =
    { order with items = order.items @ [item] }

let getTotalAmount (order: Order) =
    let total = 0.0
    for item in order.items do
        total <- total + item.price
    total

let getPrice (item: OrderItem) =
    item.product.price * item.quantity

let getTotalPrice (order: Order) =
    let total = 0.0
    for item in order.items do
        total <- total + getPrice(item)
    total
+ +

在这个示例中使用了“Order”、“OrderItem”、“Customer”和“Product”等术语，这些术语都是 Ubiquitous Language 的一部分，可以提高代码与业务需求的一致性。

+]]> + + Technique + + Dealing with complex dependency injection in FSharp /2024/10/18/Dealing-with-complex-dependency-injection-in-FSharp/ @@ -604,7 +627,6 @@ ]]> Technique - F# Archive @@ -746,7 +768,6 @@ ]]> Technique - F# Archive @@ -788,7 +809,6 @@ ]]> Technique - F# @@ -822,7 +842,6 @@ ]]> Technique - OCaml @@ -881,7 +900,6 @@ ]]> Technique - OCaml @@ -950,7 +968,6 @@ ]]> Technique - OCaml @@ -1054,7 +1071,6 @@ ]]> Technique - OCaml @@ -1174,7 +1190,6 @@ ]]> Technique - OCaml @@ -1236,7 +1251,6 @@ ]]> Technique - OCaml @@ -1333,7 +1347,6 @@ ]]> Technique - OCaml @@ -1481,7 +1494,6 @@ ]]> Technique - OCaml @@ -1515,7 +1527,6 @@ ]]> Technique - Obsidian @@ -1586,9 +1597,6 @@ ]]> Technique - Web - Typescript - Database @@ -1649,9 +1657,6 @@ ]]> Technique - Web - Typescript - Software-Engineering @@ -1682,7 +1687,6 @@ ]]> Technique - Rescript @@ -1710,7 +1714,6 @@ ]]> Technique - Rescript @@ -1732,7 +1735,6 @@ ]]> Technique - Rust @@ -1760,7 +1762,6 @@ ]]> Technique - Rust @@ -1808,7 +1809,6 @@ ]]> Technique - Rust @@ -1826,7 +1826,40 @@ 

...
    fn handlers(self) -> crate::server::request::Handlers {
        let tree = json!(self.clone().tree(self.clone().root));
        vec![(
            "/tree",
            routing::get(move || async { (StatusCode::OK, Json(tree)) }),
        )]
    }
...
]]> Technique - Rust + + + + TDD 和 DDD 的一些小想法 + /2025/03/20/TDD-%E5%92%8C-DDD-%E7%9A%84%E4%B8%80%E4%BA%9B%E5%B0%8F%E6%83%B3%E6%B3%95/ + Test-Driven Development (TDD) 和 Domain-Driven Design (DDD) 是两种不同的软件开发方法论，各自有其独特的优缺点和应用场景。

+

Test-Driven Development (TDD)

优点：

    +
  1. 提高代码质量：通过编写测试来驱动开发，可以确保代码的正确性和可靠性。
    2. +
  2. 减少缺陷：早期发现和修复缺陷，减少后期的调试和维护成本。
    3. +
  3. 促进可维护性：代码更加模块化和可测试，便于后续的维护和扩展。
    4. +
  4. 文档化：测试代码本身就是一种文档，描述了系统的行为和期望。
    5. +
  5. 提高开发速度：虽然初期可能会慢一些，但长期来看，由于减少了重构和调试的时间，开发速度会提高。
    6. +
+

缺点：

    +
  1. 初期投入大：需要在开发前编写测试，初期投入的时间和精力较大。
    2. +
  2. 学习曲线陡峭：对新手开发者来说，学习和掌握TDD需要一定的时间。
    3. +
  3. 过度依赖测试：可能导致过度依赖单元测试，忽略了系统的整体性能和用户体验。
    4. +
+

Domain-Driven Design (DDD)

优点：

    +
  1. 聚焦领域：通过深入理解业务领域，确保软件系统与业务需求紧密结合。
    2. +
  2. 模型驱动：建立一个清晰的领域模型，帮助开发者和业务专家共同理解系统。
    3. +
  3. 可维护性：通过明确的领域模型和边界，系统结构更加清晰，便于维护和扩展。
    4. +
  4. 沟通桥梁：提供了一种通用的语言（Ubiquitous Language），促进开发团队和业务团队之间的沟通。
    5. +
+

缺点：

    +
  1. 复杂性高：DDD方法论较为复杂，需要深入理解领域模型和设计模式。
    2. +
  2. 初期投入大：需要大量的时间和精力进行领域分析和建模。
    3. +
  3. 适用范围有限：对于简单的系统或小型项目，DDD可能显得过于复杂和冗余。
    4. +
+
+

TDD 和 DDD 并不冲突，实际上它们可以互补。TDD 可以帮助确保代码的正确性和可靠性，而 DDD 可以确保系统与业务需求紧密结合。在进行 TDD 时，可以使用 DDD 的领域模型和 Ubiquitous Language 来编写测试用例，确保测试覆盖了业务需求。在进行 DDD 时，可以使用 TDD 来驱动实现，确保每个领域模型的实现。

+]]> + + Technique @@ -2046,7 +2079,6 @@ ]]> Technique - Web @@ -2090,7 +2122,6 @@ ]]> Technique - TypeScript @@ -2129,7 +2160,6 @@ ]]> Technique - Database @@ -2154,7 +2184,6 @@ 
starting up ...
hello from OCaml
acquiring ...
acquired
]]> Technique - OCaml @@ -2170,7 +2199,6 @@ ]]> Technique - OCaml @@ -2181,8 +2209,7 @@

shadow-cljs.edn:

{:source-paths ["src/main"
                "src/test"]

 :dependencies [[reagent "1.2.0"]
                [re-frame "1.3.0"]]

 ;; Here
 :proxy {:host "localhost"
         :port 20171}

 :builds       {:app {:target           :react-native
                      :init-fn          example.app/init
                      :output-dir       "app"
                      :compiler-options {:infer-externs :auto}
                      :devtools         {:autoload true}}}}
]]> - Clojure - ClojureScript + Technique @@ -2195,7 +2222,6 @@ ]]> Technique - OCaml @@ -2494,26 +2520,6 @@ 我在写信
寄给羊水
信里提到
宇宙称呼它为灰
我们叫地球
还提到
风车不能骑
但是石头可以打水漂
你呀
到时别忘了
用小小的哭声款待我

我们应该坐在一起发呆
发很久的呆
然后我说人类好无聊啊
这个地球完蛋了
你点点头

-]]> - - gallery - - - - 二〇二四年五月十六日 - /2024/05/16/%E4%BA%8C%E3%80%87%E4%BA%8C%E5%9B%9B%E5%B9%B4%E4%BA%94%E6%9C%88%E5%8D%81%E5%85%AD%E6%97%A5/ - 无眼耳鼻舌身意，无色声香味触法，四下皆空，但万物有实，活在真实世界，而非活在一系列参照物之中。

-

不要有所谓自信或自卑的概念。要意识到，心态这玩意本质就是从比较中产生的，镜花水月般的东西，毫无力量可言。

-

人若把自己的心态放置在客观事实和规律前面，无可避免就会产生内耗。而现代人这一生绝大多数的痛苦，都是内耗所带来的。

-

多尝试点事情吧，试得越多，就能越快判断出自己是不是这块料。如果是，很好；如果不是，过，下一个。在这期间不要有任何心态波澜，行就是行，不行就是不行。反正不是非行不可。

-

人自信不是样样精通、事事皆成，凡事都做得比别人更好；自信是一个高级陷阱，仰赖自信的人终有一日会崩塌于自信的毁灭。

-

用生命力来取代往日的自信心，用绝对强大的权力意志来取代往日相对成功的小胜小利。

-

不放弃的理由不是因为自信，而是因为知道这事必须得干/行得通；放弃的理由也不是因为不自信，而是因为知道这事不能去干/行不通。

-

而一旦在理性和感性层面都认为必须办成某件事，那就不顾一切去办成。哪怕绕再多的路，要办的事就是要办。

-

当不再局限于自信或自卑，而是立足于实事求是去布局和行动，一切都会变得更加清晰明了。若想成事，首先要花时间去搞明白自己的长处与短板，然后学会在面对具体事项之际快速判断自己行不行、是不是非做不可、要做的话又有几分把握、失败了要如何应对、要不要改变其中某些变量再多试几次。

-

当有了一个目标，需要的不是豪言壮志，不是任何心理建设，而是尽快上手去做。
做一件事，无关心态，只要去做就是了。发挥最大的主观能动性，遇到问题就解决，碰到障碍就破开，需要帮助就求助。别因为所谓的自信就盲目冒进，也别因为所谓的自卑就胆小退缩，那俩玩意都不存在。

-

尊重事情本身的客观发展规律，什么样的人匹配什么样的事，什么样的条件匹配什么样的理想。别把心态想得太重要，更别花太多时间精力去建设心态，客观规律不会因为心态就发生奇迹般地转变。

-

你最好趁早学会尊重客观规律。

]]> gallery @@ -2542,6 +2548,26 @@

早上七点。

太阳完全绽放的光芒照亮了这个欣欣向荣的世界，有山、有海，有自由。

+]]> + + gallery + + + + 二〇二四年五月十六日 + /2024/05/16/%E4%BA%8C%E3%80%87%E4%BA%8C%E5%9B%9B%E5%B9%B4%E4%BA%94%E6%9C%88%E5%8D%81%E5%85%AD%E6%97%A5/ + 无眼耳鼻舌身意，无色声香味触法，四下皆空，但万物有实，活在真实世界，而非活在一系列参照物之中。

+

不要有所谓自信或自卑的概念。要意识到，心态这玩意本质就是从比较中产生的，镜花水月般的东西，毫无力量可言。

+

人若把自己的心态放置在客观事实和规律前面，无可避免就会产生内耗。而现代人这一生绝大多数的痛苦，都是内耗所带来的。

+

多尝试点事情吧，试得越多，就能越快判断出自己是不是这块料。如果是，很好；如果不是，过，下一个。在这期间不要有任何心态波澜，行就是行，不行就是不行。反正不是非行不可。

+

人自信不是样样精通、事事皆成，凡事都做得比别人更好；自信是一个高级陷阱，仰赖自信的人终有一日会崩塌于自信的毁灭。

+

用生命力来取代往日的自信心，用绝对强大的权力意志来取代往日相对成功的小胜小利。

+

不放弃的理由不是因为自信，而是因为知道这事必须得干/行得通；放弃的理由也不是因为不自信，而是因为知道这事不能去干/行不通。

+

而一旦在理性和感性层面都认为必须办成某件事，那就不顾一切去办成。哪怕绕再多的路，要办的事就是要办。

+

当不再局限于自信或自卑，而是立足于实事求是去布局和行动，一切都会变得更加清晰明了。若想成事，首先要花时间去搞明白自己的长处与短板，然后学会在面对具体事项之际快速判断自己行不行、是不是非做不可、要做的话又有几分把握、失败了要如何应对、要不要改变其中某些变量再多试几次。

+

当有了一个目标，需要的不是豪言壮志，不是任何心理建设，而是尽快上手去做。
做一件事，无关心态，只要去做就是了。发挥最大的主观能动性，遇到问题就解决，碰到障碍就破开，需要帮助就求助。别因为所谓的自信就盲目冒进，也别因为所谓的自卑就胆小退缩，那俩玩意都不存在。

+

尊重事情本身的客观发展规律，什么样的人匹配什么样的事，什么样的条件匹配什么样的理想。别把心态想得太重要，更别花太多时间精力去建设心态，客观规律不会因为心态就发生奇迹般地转变。

+

你最好趁早学会尊重客观规律。

]]> gallery @@ -3285,7 +3311,6 @@ ]]> Technique - Web @@ -3935,6 +3960,55 @@ Life + + 肺功能检查数值 + /2025/03/20/%E8%82%BA%E5%8A%9F%E8%83%BD%E6%A3%80%E6%9F%A5%E6%95%B0%E5%80%BC/ + 肺功能测试是评估患者呼吸系统健康的重要工具。各个指标的及其异常数值可能指示的潜在生理疾病：

+

1. FEV1（第一秒用力呼气量）

    +
  • 评估：FEV1用于评估气道的通畅程度。它反映了在用力呼气的第一秒内，患者能够排出的气体量。
    • +
  • 异常：FEV1降低通常提示气道阻塞，常见于慢性阻塞性肺病（COPD）、哮喘、支气管炎等疾病。
    • +
+

2. FVC（用力肺活量）

    +
  • 评估：FVC测量的是患者在一次用力呼气中能够排出的最大气体量，反映了肺的容量和扩张能力。
    • +
  • 异常：FVC降低可能指示限制性肺病，如肺纤维化、胸廓畸形或神经肌肉疾病等。
    • +
+

3. FEV1/FVC比值

    +
  • 评估：FEV1/FVC比值用于区分阻塞性和限制性肺病。正常情况下，该比值应大于70%。
    • +
  • 异常：
      +
    • **低于70%**：提示气道阻塞，常见于COPD和哮喘。
      • +
    • **正常或高于70%**但FVC降低：可能提示限制性肺病。
      • +
    +
    • +
+

4. PEF（峰值呼气流量）

    +
  • 评估：PEF测量患者在用力呼气时达到的最大流速，常用于监测哮喘患者的病情变化。
    • +
  • 异常：PEF降低可能提示气道狭窄或阻塞，常见于哮喘急性发作或COPD加重。
    • +
+

5. MVV（最大通气量）

    +
  • 评估：MVV测量在一定时间内（通常是12秒）能够进行的最大通气量，反映了肺部的通气能力和呼吸肌的力量。
    • +
  • 异常：MVV降低可能与呼吸肌无力、气道阻塞或肺部疾病（如COPD）相关。
    • +
+

6. TLC（总肺容量）

    +
  • 评估：TLC测量肺部在最大吸气后所能容纳的气体总量，反映了肺的整体容量。
    • +
  • 异常：
      +
    • 增加：可能与阻塞性肺病（如COPD）相关，因肺部过度膨胀。
      • +
    • 降低：可能与限制性肺病（如肺纤维化、胸廓畸形）相关。
      • +
    +
    • +
+

7. RV（残气量）

    +
  • 评估：RV测量在最大呼气后，肺内仍然残留的气体量。
    • +
  • 异常：
      +
    • 增加：常见于阻塞性肺病，因气道阻塞导致气体无法完全排出。
      • +
    • 降低：可能与限制性肺病相关。
      • +
    +
    • +
+]]> + + Medicine + + 肺炎支原体注意事项 /2023/10/25/%E8%82%BA%E7%82%8E%E6%94%AF%E5%8E%9F%E4%BD%93%E6%B3%A8%E6%84%8F%E4%BA%8B%E9%A1%B9/ @@ -5518,7 +5592,6 @@ ]]> Technique - OCaml @@ -5544,7 +5617,6 @@ ]]> Technique - Software Engineering -- cgit v1.2.3