區塊鏈上的程式架構與設計
在本文中，我們將介紹標準區塊鏈應用程式架構、用於區塊鏈應用程式開發的各種components和工具以及 IDE。
除了讀寫區塊鏈之外，大多數開發區塊鏈應用程式與開發非區塊鏈應用程序沒有太大區別。 區塊鏈開發的應用程序通常被稱為去中心化應用程式、DApp、dApp、dapp 或 DApp。
另外我們也將介紹如何設計區塊鏈應用程式或解決方案。 區塊鏈應用程式的設計應該與組織的任何其他企業專案一樣，從定義解決方案本身的指導原則開始。
區塊鏈的程式架構
開發區塊鏈應用程式類似於典型的Full stack Web 應用程式開發，通常稱為multi-tiered application。典型的區塊鏈應用包括user interaction layer、middle/interface layer和blockchain layer。
User interaction包括由 HTML/CSS 和移動技術組成的一個或多個presentation layer。在開發區塊鏈應用程式時，這一層沒有任何特殊或新的要求。區塊鏈應用程式的用戶體驗應該設法讓用戶理解和重視區塊鏈提供的任何新的或不同的功能。
Middle/interface layer是連接區塊鏈本身的gateway，並提供與區塊鏈之間的所有通訊。用 Node.js 編寫的server-side code是為區塊鏈應用程式提供所有應用程式的邏輯以及智慧合約接口的技術。這個code代理user與區塊鏈本身之間的通訊。
與區塊鏈之間的所有通訊都是bytecode。middle layer通過使用 JavaScript library將bytecode的translation從user layer和middle layer中抽像出來。middle layer應該包含所有應用程式驗證和異常處理代碼，一些開發人員也會在這裡實現業務邏輯，但有些開發人員也會在他們的區塊鏈層的智慧合約中實現這個邏輯。通常來說middle layer是在三個layer中最複雜的。
Blockchain layer是發布、存儲和驗證智慧合約（或稱codechain）及其交易的地方。 智慧合約被轉換為bytecode，發佈到區塊鏈並像任何其他區塊鏈交易一樣進行驗證。
智慧合約可以呼叫其他智慧合約。 預設情況下，智慧合約無法連接外部資料，但可以通過使用 Oracle 來克服這一限制。 Oracle是可信的資料源，可以將訊息發送到智慧合約中。 Oracle通常由第三方提供，但也可以獨立開發。
其他一些需要熟悉的工具和框架包括：
- Web3.js 框架 — 用於以太坊智慧合約的code execution
- JSON-RPC library — 用於呼叫智慧合約功能
- Ganache(以前稱為TestRPC) — 使用本機區塊鏈模擬進行測試和開發
- Truffle — 一個工具和發佈區塊鏈應用程式的管理系統，允許在以太坊測試和生產區塊鏈上進行部署和測試。
IED(Integrated Development Environment)
由於大部分區塊鏈應用程式與其他應用程式相同，因此在構建區塊鏈應用程式時可以使用許多主流 IDE。任何 HTML、CSS 和 JavaScript 編輯器或 IDE 都適用於區塊鏈應用程式的初始開發層，包括大多數開源代碼編輯器（如 Visual Studio Code）以及一些付費編輯器。大多數 IDE 都有適用於以太坊和 Hyperledger 的插件。
鑑於去中心化的性質以及區塊鏈中的一切都發生在protocol level，區塊鏈應用程式和智慧合約的開發確實需要一些特殊的工具。我們所需要的智慧合約開發工具將視我們使用的的區塊鏈技術類型。如果使用以太坊區塊鏈，那麼我們將通過 Solidity (SOL) 語言開發和連接區塊鏈。
開始開發以太坊智慧合約的最佳方法之一是使用 Remix。 Remix 是一個用於以太坊區塊鏈智慧合約開發的線上IDE開發環境。 Remix 專注於 Solidity 智慧合約的開發和部署。 Remix 是一個很好的解決方案，能夠提供：
- 開發智慧合約(remix整合了solidity編輯器)
- 智慧合約執行的debug
- Access已經部署的智慧合約的狀態和屬性。
- Debug已經提交的transaction。
- 分析 Solidity code以減少編碼錯誤並執行最佳實踐
如果使用 Hyperledger 區塊鏈，那麼我們很可能會通過 Hyperledger Composer 開發和連接區塊鏈。 "Hyperledger Composer 讓我們的業務網路建模並將現有系統和資料與我們的區塊鏈應用程式整合"。 Composer 是用於開發 Hyperledger 網路和應用程式的工具集和框架。
Hyperledger Fabric 中的所有功能都稱為“Intake”或“Deploy” transaction。 Deploy transaction將新的asset部署到區塊鏈，而這些asset則會呼叫intake function。 client app通過使用 SDK 與chaincode進行通訊。
Hyperledger 資料庫 — Hyperledger Fabric 中的ledger system使用 levelDB。 根據定義，LevelDB 允許concurrent writer通過提供內部同步來安全地將資料寫入到資料庫。 LevelDB 使用very coarse-grained synchronization，強制所有的資料寫入以順序、先到先服務的方式進行(firstcome-first-served basis)，有效地降低了single thread的tjroughput。 State Database 選項包括 LevelDB 和 CouchDB。 LevelDB 是嵌入在peer process中的預設 key-value 資料庫。 CouchDB 則是一個可以選擇性的外部State Database。
DAO’s — 區塊鏈解決方案中有一種架構模式稱為 DAO (Decentralized Autonomous Organization)。 DAO 是一個由許多智慧合約組成的解決方案，主要取代許多組織中本來的人工作業。 DAO 架構模式允許公司和企業的形成一個社群或類似同業公會，它們比傳統的同業公會更精簡，地理分佈更廣。
我們應該如何設計BlockChain App?
設計的指導原則
指導原則應該是一系列是或否的問題，我們的團隊和組織必須在開始解決方案設計之前就這些問題達成一致性的共識。 答案將定義解決方案的預定或假定視圖(assumed view)。 這並不意味著我們的解決方案不能或不會做相反的事情，只是如果需要做相反的事情，它需要被證明。
一些指導原則的例子包括：
• 我們的解決方案是"feature-heavy 還是feature-light"？ 換句話說，我們是提供盡可能多的功能，還是我們主要是提供一個簡單的應用程式？
• 協同作業和安全哪個更重要？ 換句話說，我們是支持開放和順暢的協同作業，還是希望確保最高等級的安全性？
• 協助是中心式的還是去中心化的？ 換句話說，如果用戶有問題或需要幫助，他們會直接來找我們，還是應該向社群尋求幫助？
- 我們為用戶提供的解決方案是否具有一致性或專業性？ 換句話說，我們的解決方案是否會一視同仁地對待所有用戶並授予他們相同的訪問權限和操作權限，或者該解決方案是否允許用戶在他們想要的領域進行專業化和發展？
而指導原則將有助於定義角色。
角色(Personas)
角色是將使用我們的區塊鏈應用程式或解決方案的用戶類型。每個人都可以是多個角色，而角色也不是單一個人。
範例角色#1：Vanessa是一位忙碌的會計人員，她對當前業務流程中涉及的書面資料工作感到沮喪。她認為，如果她參與的流程能夠簡單地採用現代工具集，她可以完成更多工作。她經常在工作中變得氣餒和沮喪，並想知道其他組織是否比她的工作做得更好。尤其處理費用報銷過程對她來說尤其痛苦。
範例角色#2：Fanny喜歡美食烹飪，週末她喜歡嘗試準備新菜色並與朋友分享。她喜歡通過非主流的食譜來加上自己的風格來進行實驗。通常，她會想出一些她認為非常好的新菜色。她希望有一種更簡單的方式來分享這些創作，並與其他業餘廚師就烹飪理念進行合作。
而角色將有助於建立User stories。
User Stories
User stories是關於角色的短篇故事，以及他們將與我們的區塊鏈應用程式或解決方案進行所需的交互動作。 user sotries應該定義每個角色在特定use case中如何與我們的解決方案交互，並描述預期的結果。
角色範例：Vanessa 很高興她公司的區塊鏈費用報銷系統上線。 Vanessa每個月月底一次檢查所有的費用報銷作業。 她可以批次的批准或拒絕這些申請。 也可以通過one click快速查看單一記錄並批准或拒絕。 任何被拒絕的費用都可以發回提交者進行更改或刪除。 所有批准的費用都會發送到會計部門，而 Vanessa無需做任何額外的事情。 Vanessa認為這是一個比紙張的文書處理作業好得多的系統，因為她自上線以來體驗到了巨大的效率提升。
User stories將有助於建立functional requirements。
Functional Requirements
Functional requirements描述了解決方案應該做什麼(done)，而不關注應該如何做(how)。 從前面的user stories中，我們可以提取出這些functional requirements：
• 快速查看過去一天所有提交的費用申請
• 一鍵式的批准或拒絕每項費用
• 可以將被拒絕的費用發回提交者或刪除
- 批准的費用用於AP處理
Functional requirements將推動technical requirements。
Technical Requirements
Technical requirements解釋如何滿足functional requirements。 在我們的範例中，functional requirement可以分解為以下的technical requirements：
Technical requirements將會定義出開發作業(development tasks)．
Tasks
Tasks是為滿足technical requirements而必須採取的明確步驟。 在我們的範例中，technical requirements可以分解為以下的tasks：
一旦我們進入到task level，就可以為每個task提供估算值(要花多少時間)。 還應對每項task進行評估，以確定要完成這個task所需要的技能(skillset)/資源。 一般來說，如果一項tasks無法估計或無法識別skillset，則需要將task進一步分解為sub-tasks。
在我們的範例中，可以估計tasks並將其與skillset匹配：
區塊鏈架構的基本性問題
當我們提出一個專案或解決方案時，優秀的架構師會努力確保我們的團隊、組織和提議的專案本身都能獲得成功。 要正確定位專案以獲得成功並確定區塊鍊是否是正確要使用的技術，會有以下問題：
- 這個解決方案能讓用戶做什麼？
- 提議的解決方案是否會減少或消除用戶當前感受到的問題和痛點？
- 這個解決方案應該不讓用戶做什麼？
- 我們是否需要在第一天就可以大量使用的解決方案？
a. NO=區塊鏈技術, Yes= 傳統技術 - 使用區塊鏈是否加強了我們的解決方案想法？ 區塊鏈的使用是否創造了更好的用戶體驗？ 如果是這樣，怎麼做？
a. No = 傳統技術 , Yes = 區塊鏈技術 - 公司以前是否開發過客制的軟體方案？
a . Yes
i, 公司是否有足夠的能力直接或間接地對開發人員進行區塊鏈技術訓練？
ii. 公司是否已經擁有良好的開發營運流程和實踐(如敏捷開發/DevOps等)？
iii. 公司會外包開發、專案管理、架構或用戶體驗設計嗎？
b. NO
i, 公司想在內部開發還是外包？
ii. 公司是否有一個解決方案的想法，或者公司是否設建立建多個解決方案？ - 我們需要什麼等級的支援？
- 開發者社群有多大？
- 公司對未來的願景是否與專案或平台對未來的願景是一致的？
- 這個平台是否主要在為開發社群中做出新的重大貢獻，還是效率/成本？ 哪個對我們更重要？
- 如果選擇Private blockchain，如何授權、控制和規範成員資格和訪問權限？
- 解決方案應該是Open的還是Closed 的blockchain？
- 誰需要查看資料？ 誰不應該看到資料？
- 它需要多快？
a. 更快的速度（Private Blockchain）= 更低的可信度（更小的網路規模）
b. 較低的速度（Public Blockchain）= 較高的信任度（較大的網路規模）
我們的解決方案是否會使用或需要智慧合約之類的功能？ 如果是這樣，請為合約的updates和changes制定計劃。 需要記住，一旦部署了合約，它就是永久的，除非它的 Kill/Self-Destruct 方法被呼叫。 如果使用 Kill 函數，請確保它不會被惡意或間接地呼叫。 如果update了合約，則會在新舊合約會同時並存。 由於區塊鏈的永久性，請確保我們知道應用程式將如何知道使用update或change後的合約。
最後，區塊鏈不是一刀切的解決方案或技術！ 混合解決方案 — 使用傳統資料存儲和系統以及區塊鏈的解決方案可能是最佳選擇。
最後，永遠都要問自己以下問題：
• 我們所選的角色符合指導原則嗎？ 如果沒有，是否有正當理由不這樣做？
• 我們的user stories是否符合指導原則？ 如果沒有，是否有正當理由不這樣做？
• 我們的functional requirements是否符合指導原則？ 如果沒有，是否有正當理由不這樣做？
• 我們的technical requirements是否符合指導原則？ 如果沒有，是否有正當理由不這樣做？
• 我們的task是否符合指導原則？ 如果沒有，是否有正當理由不這樣做？
