# ShinGo讀書筆記

## abp
IDDD那本第28頁有issue concept example (issue aggregate)
讀完abp這兩本書
應該可以指導同事哪些功能要放在哪一層boundraries要怎麼切分

## DDD

https://ddd-crew.github.io/ddd-starter-modelling-process/

### Event Storming
https://www.eventstorming.com/

## api first & as product

91app首席架構師Andrew
https://columns.chicken-house.net/

104API
https://developers.104.com.tw/swagger-ui/?urls.primaryName=4

Linkedin API
https://developer.linkedin.com/product-catalog

OpenAI API
https://openai.com/api/

## Webhook
使用 Webhook 和連接器將您的應用程式與 Microsoft Teams 整合
https://learn.microsoft.com/zh-tw/events/build-may-2021/microsoft-365-teams/connection-zone/con066/

## Angular

https://morioh.com/p/9c3f140e8d75?f=5e465398856ed07d4dcd73ed

## 顧問輔導 & WebAPI

顧問部落格
Bruce Chen ([e-mail])
https://blog.kkbruce.net/

### Clean Architecture
https://ithelp.ithome.com.tw/articles/10268953
Clean Architecture 把系統分成四層，這四層不是由上而下排列，而是由外而內排。 排列的依據為：「越細節的越外面，越核心的越裡面。」這四層分別為：

Entities
核心業務、重要資料所在地。不管你在什麼場景，做什麼操作，在你的問題領域中不論有沒有系統幫忙，你都必須得做的事。

Use Cases
這一層包圍在 Entity 之外，定義著對於 Entity 邏輯與資料的使用時機與操作順序，是一個管「自動化」的傢伙。

Interface Adapters
系統的邊界，對外取得請求內容，轉換成內層認識的樣貌、並尋找適當的 Use Case 來執行任務，最後再轉換成外界認識的樣貌送出去。同時，系統對外發出的請求，也會在這一層轉換。

因為位處系統邊界，做的事大多都是一些轉換的工作，所以命名為 Interface Adapter。

Frameworks & Drivers
系統中最細節的部分，大部分都是 I/O，舉凡網路、檔案、資料庫、人機介面等，都屬於此範圍。

那麼什麼叫核心，又什麼叫細節呢？實際操作時，其實就是：「離 I/O 越近的越細節，在外層；離 I/O 越遠的越核心，在內層。」

Uncle Bob 說：「Entity 與 Use Case 是你生意能經營的主要推手，必須慎重對待。I/O 雖然有重要，但是是重要的細節，應該要可以簡單被抽換。」

這裡留個思考題：「Data driven 與 UI driven 的開發方式，與 Clean Architecture 搭配使用的話，會發生什麼事呢？」

三大原則
Clean Architecture 討論了很多設計上的注意事項，而簡言之可以歸納出三大原則：

分層原則：如上一節所述，所有系統元件應該要分門別類安置，不要亂放。
依賴原則：依賴應該要盡量「由外而內」，不能「由內而外」，否則依賴關係會亂掉，造成不必要的耦合。
跨層原則：外層只能認識同一層或往內一層的元件，不能認識「兩層以外」的任何元件。

## Code first

EF Core only have 2 ways:
1.Code first
2.Code first from db
https://ithelp.ithome.com.tw/articles/10208501

https://www.ryadel.com/en/code-first-model-first-database-first-vs-comparison-orm-asp-net-core-entity-framework-ef-data/

代碼優先方法具有以下優點：

不需要任何圖表和可視化工具，這對於中小型專案非常有用，因為它可以為我們節省大量時間
一個流暢的代碼 API，允許開發人員遵循約定優於配置的方法來處理最常見的方案，同時還讓他有機會在需要自定義資料庫映射時切換到自定義的、基於屬性的實現覆蓋
然而，它也有這些缺點：

需要對ORM程式設計語言和約定（用於實體框架的C#）有很好的瞭解
維護資料庫有時可能很棘手，以及在不丟失數據的情況下處理更新;實體框架的遷移支援極大地緩解了問題，儘管它也以負面的方式影響了學習曲線

做出選擇
通過選項的優缺點，沒有整體更好或最好的方法;相反，我們可以說每個專案方案都可能有一個最合適的方法。

但是，只要我們處理一個相當小的專案（例如微服務）和/或我們的目標是靈活、可變的小規模數據結構，採用代碼優先方法幾乎總是一個不錯的選擇。

## Git

https://andrewintw.github.io/introduction-to-version-control-with-git/