盛安德分享：我們如何從DDD中受益？

摘要： DDD原則是開發軟體需要從業務需求開始。通常傾向於關注技術細節，但通過這種模式，設計基於核心業務目的和邏輯，同時可考慮到公司的戰略方向。企業應用程式可能非常複雜，因此我們的團隊使用了一種將使用者（領域專家）連線到需求定義的開發技術，目的是構建可轉換為解決業務需求的軟體。 在本文中，我想分享...

DDD原則是開發軟體需要從業務需求開始。通常傾向於關注技術細節，但通過這種模式，設計基於核心業務目的和邏輯，同時可考慮到公司的戰略方向。企業應用程式可能非常複雜，因此我們的團隊使用了一種將使用者（領域專家）連線到需求定義的開發技術，目的是構建可轉換為解決業務需求的軟體。

在本文中，我想分享一下我們如何從領域驅動設計中受益的經驗

在我遇到領域驅動設計之前

在Shinetech，我們多年來一直從事敏捷實踐，Scrum已成功應用於我們的大多數專案中。由於行業敏捷大師和國內優秀軟體工程師的共享和推動，我們使用了許多優秀的軟體開發實踐，如TDD，BDD，CI等，所有這些都為我們帶來了巨大的利益。由於我們主要專注於為客戶開發專案，儘管這些實踐可以提高軟體交付質量和開發效率，但如果我們想以最佳方式使用它們，它實際上涉及很多因素。以一些常見的場景為例：

• Scrum專案需要產品負責人Product Owner角色，但客戶很少有這樣的角色與Scrum定義相一致 。
• BDD對客戶的需求甚至更高，他們需要編寫具體，情景，給定......當......然後。我經歷了一個專案，客戶在開始時寫了BDD，真正的高質量BDD，然而，他停止寫它，因為他認為它太麻煩了。
• 在我們的專案中主要使用.NET，儘管每個人都熟悉面向物件，類，介面，繼承，封裝等，但在涉及如何正確地抽象業務或使用時，對我們來說仍然是一個巨大的挑戰。以正確的方式面向物件。
• 使用敏捷方法時，與傳統的開發過程不同，後者提供詳細的需求規範（假設規範及時更新，描述準確且易於理解），敏捷強調可行的軟體。但是，正如我們所知，有很多業務邏輯難以通過介面反映，即使有使用者故事，PO產品負責人很難編寫與SMART規則一致的使用者故事，常見的情況是通常像這樣 - PO表達了一個粗略的想法或要求場景，程式設計師“立即明白了這個想法”，他們最終開發了一個通過驗收測試的軟體，但是，因為有測試和反饋修復，這些要求實際上“丟失了” ”。
• 資源變化是軟體行業中的常見現象，但通常小團隊中沒有備用資源，因此當資源發生變化時，如果沒有好的方法進行知識轉移，專案相關的上下文很容易丟失; 即使人們試圖在知識轉移方面做得很好，它仍然存在很大的挑戰，因為當人們決定離開時，他的思緒首先如何離開並且難以專注於當前的工作，所以我們能做的就是盡力減少因為專案相關的背景導致的損失。

在我建立Shinetech西安分公司的前幾年，我致力於在我們的分公司進行敏捷實踐和其他良好的軟體開發實踐，我們從中受益匪淺 - 我們團隊的軟體技能得到了很大提高，他們熟悉了有很多清潔程式碼的東西，瞭解單元測試，CI，GitFlow等的重要性和好處。但是，我也同時考慮以下問題：

1. 如何減少客戶反饋中的錯誤？雖然敏捷強調經常與客戶進行互動和反饋，以便在開發過程中儘早出現錯誤，而不是通過多次修改獲得正確的結果，但首先做正確的事情肯定會提高專案交付速度，這也可以節省成本我們的客戶，提高我們的程式設計師的效率。
2. 資源變化過程中的知識轉移。雖然我們可以通過清晰的軟體架構，清晰的程式碼和高單元測試覆蓋率來高度提高新資源對專案的理解速度，但是新的人力資源仍然需要很長時間才能讀懂使用者故事、單元測​​試和各種分佈在不同級別中的程式碼（各個級別程式碼都有相關負責單位，但這並不意味著我們不需要單位責任）。
3. 開發人員的軟體技能，工作效率和生產力的提高，以及開發人員薪水的提升，我認為這是我作為分公司經理的首要責任。從其他方面來說，我認為一些相對簡單的專案，如CRUD專案，或者一些前端專案，如Angular / React專案，在市場上的能力會越來越低（我並不是要貶低前端，只是意味著進入這種已經存在的框架的門檻比較低）。因此，我們應該選擇更加“艱難”的專案 - 具有複雜業務和需求的專案，只有這些型別的專案可以快速提高開發人員的能力並增加他們的費率促銷的可能性。

追求卓越的軟體！在以前，我總是強調質量和效率的重要性，但是對於其他人來說理解並能應用卻並不容易，突然有一天，我想到了這一點（或者我從某個地方看到它）：兩個最重要的問題應該是在軟體開發中解決：

做正確的事

做正確的事