架構層級的「開閉原則」（the-open-closed-principle，簡稱ocp原則）含義是：乙個類對擴充套件是「開」放的，而對變更是封「閉」的，意思是說，應該在不改變類的前提下擴充套件乙個類的行為。而通常的方式是繼承和多型。在架構層級，我們並不會變更系統的一部分功能（可能是最適用於當前架構的程序，守護程序，服務，或者微服務），而是通過新增功能的方式來復用已完成的**。為了不對現有的部分做出變更，系統需要做到完全的解耦。接下來的內容將聚焦於事件驅動系統，並以訊息佇列實現服務間通訊。訊息佇列可以是activemq,rabbitmq,zeromq,kafka或者其他服務，我將以kafka的話語體系來進行描述，如主題（topic），發布者，訂閱者，以及類似kafka的多個訂閱者共享相同主題的能力。
迪公尺特法則（law of demeter）又叫作最少知識原則（least knowledge principle 簡稱lkp），就是說乙個物件應當對其他物件有盡可能少的了解。事件主要的目標就是傳達某事已經發生的訊息，並提供與這一事情相關的有用的資料。用於為系統構建資料流的事件，一般是應用於大資料系統中。在大資料系統中充斥著橫跨系統範圍內大量的資訊，資訊在傳遞過程中會經過多次轉換。可以讓事件附加我們所能提供的盡量多的資訊，以便減少在資訊轉換所帶來的額外的成本。我們所能採取的最好的方案是，在訊息中提供足夠的資訊，既滿足我們最初的設計中所考慮到的用例場景的需要，同時也要讓這些資訊對我們可能尚未考慮到的新的服務是可用的。比如把主要的有界上下文的實體的id引入進來，這些實體要麼是我們與事件通訊的事實的乙個組成部分，要麼與之相關。新的微服務需要涵蓋很多的實體，當然，這會打破「迪公尺特法則」，但這是必要的妥協。軟體架構的要義即在於此：做出恰當的權衡以達成盡量好的系統。遵循開閉原則的能力是如此的重要而有意義，從某種程度上講，我們可以為此不惜違背「迪公尺特法則」。
1、事件驅動系統給了我們很好的機會來在架構層級應用開閉原則。我們可以重用已有的**，並且在未知的方向上實現功能的擴充套件。
2、然而，需要謹慎的設計事件的內容，同時警惕糟糕的設計可能引入的耦合的可能性。
3、要根據系統的目標來指導架構設計，為某一目標設計某種適用的架構（如，為大資料系統設計的流式資料）很可能對於另一目標來說是糟糕的設計（不適用於表徵事實發生的事件驅動系統）。
4、領域驅動設計的有界上下文可以為事件內容的設計提供一些指導。
5、架構是關於決策和權衡，最大化應用開閉原則很可能意味著對「迪公尺特法則」的最小化遵循，必須謹小慎微地尋找乙個平衡點。
閱讀筆記12
軟體開發過程一般分為以下6個階段 對所要解決的問題進行總體定義，包括了解使用者的要求及現實環境，從技術 經濟和社會因素等3個方面研究並論證本軟體專案的可行性，編寫可行性研究報告，解決問題的方案，並對可供使用的資源 如計算機硬體 系統軟體 人力等 成本，可取得的效益和開發進度作出估計。制訂完成開發任務...
12月閱讀筆記
程式設計師的修煉之道 從小工到專家 第七章 在專案開始之前 需求只坑完美，不是在沒有什麼需要增加，而是在沒有什麼需要去掉時達到的。不要蒐集需求而要挖掘他們！與使用者一同工作，以像使用者一樣思考！解開不可能解開的謎題 解開謎題的關鍵 確定加給你各種約束，並確定你確實擁有自由度 不要在盒子外思考，要找到...
《架構漫談》閱讀筆記
在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構的 當然在個人來講，同一時刻只能做有限的事情，在時間上還是可能會產生架構的 一旦產生的分工，就把所有的事情，切分成由不同角色的人來完成，最後再通過交易，使得每個個體都擁有生活必須品，而不需要每個個體做所有的事情，只需要每個個體做好自己擅長的...