7
我目前正在構建基於Node.js微服務的應用程序，並且我想利用領域驅動設計作爲準則來構建單個服務。我對此有幾個問題如下：Domain.js的領域驅動設計
- 據我瞭解，領域層通常應該存放庫接口，這些接口的具體實現應該然後在基礎設施層創建。這會將您的域層的底層存儲/技術問題抽象出來。在我的項目中，看到JavaScript本身不支持支持像界面這樣的東西，如何才能實現類似的效果？
- 特別是一項服務將通過OAuth處理認證。人們通常會將與OAuth相關的邏輯歸類爲應用程序服務嗎？或者它會屬於基礎設施層？我的理解是，它不是基礎設施相關的，也不是與核心領域相關，但仍然是爲客戶提供服務的一部分。因此，我現在已將它放在應用程序層中。
- 從第2點開始，OAuth相關實體/存儲庫（即令牌/客戶端）的最佳放置位置在哪裏？儘管它們在技術上不是業務問題，但我仍然試圖將它們與我的其他實體/存儲庫一起保留在域層中。
的一些注意事項要添加到上面：
- 我使用打字稿（如建議here）不熱衷。
- 我完全知道，有些人可能認爲JavaScript不適合DDD類型的方法。我熟悉一些陷阱，並且再一次使用DDD作爲指導。
在一個側面說明，我想出了下面的項目結構，這在很大程度上受到基於DDD項目的this很好的例子，在Laravel啓發：
app/
----app.js
----package.json
----lib/
--------app/
------------service/
----------------oauth.js
----------------todo.js
--------domain/
------------list/
----------------model.js
----------------repository.js
----------------service.js
------------task/
----------------model.js
----------------repository.js
----------------service.php
--------http/
------------controller/
----------------list.js
----------------task.js
------------middleware/
----------------auth.js
----------------error.js
--------infrastructure/
------------db.js
------------logger.js
------------email.js
我很樂意聽到你可能對這個佈局有任何想法。我完全意識到項目結構的主題有點基於意見，但我總是熱衷於聽取其他人的意見。
您是否認爲DDD設計會告訴您需要選擇哪些名稱才能在項目中使用子目錄？我對這件事的瞭解聽起來好像不是那個細節。這看起來更像是確保您在一個地方架構業務模型邏輯，並保留所需的其他所有支持內容（例如，用戶身份驗證和其他簡單的基礎設施內容），但與實際業務邏輯無關在一個不錯的方便的獨立的地方 – jfriend00
@ jfriend00完全同意。也就是說，在我看來，DDD的主要驅動力 - 建立在「核心業務領域」之上。也許爲了澄清，我會編輯我的帖子，以突出我不太關注結構/命名的事實，更多的是確保正確的分類/分離。 –
但是，您的整個問題聽起來像是關於將目錄放入哪些目錄，而不是定義應用程序中的核心業務邏輯，以及如何將其與其他任何應用程序分開構建。坦率地說，其他事情並不是那麼重要（例如什麼是服務和什麼是基礎設施）。這些只是標籤，應該選擇使您的項目佈局清晰並且方便使用。 – jfriend00