1. 目標：solid、stable software
   1. 降低risk
      1. consider key scenarios
         1. 該系統的核心Scenario究竟為何？也就是該系統到底要達到什麼樣的目的
      2. design for common problems
         1. 20％的力氣解決80％的問題
      3. appreciate the long term consequences of key decisions
         1. 計畫不如變化，變化不如長官一句話
   2. poor architecture
      1. unstable
         1. 硬幹
      2. unable to support existing or future buiness requirement
         1. RFP可能沒有的
      3. difficult to deploy or manage in a production environment
         1. 例如MSDTC的問題
   3. consider issue
      1. outline
         1. key scenarios
         2. identify important quality attributes
            1. reliability
            2. scalability
            3. performance
            4. security
         3. key areas of satisfaction and dissatisfaction
            1. 哪一些重點是User最重視的點，一定要達成的點，哪一些點是可以妥協的
      2. 三者之間的 trade off
         1. User experience
         2. Performance
         3. invest hardware or software
   4. 設計架構時，應把重心放在major components and elements
      1. data structures and algorithms or implementation不是這時候想的
      2. 很容易不小心就從抽象跳到實作
   5. construct architectural solutions that address all of the relevant concerns, can be deployed on your chosen infrastructure, and provide results that meet the original aims and objectives
      1. How will the users be using the application?
         1. User要怎麼用這系統
      2.  How will the application be deployed into production and managed?
         1. 系統怎麼部署與管理
      3. What are the quality attribute requirements for the application, such as security, performance, concurrency, internationalization, and configuration?
         1. 系統的關鍵指標有哪一些？安全？效率？整合？可靠度？彈性？
      4.  How can the application be designed to be flexible and maintainable over time?
         1. 如何設計系統保持持續的彈性與可維護性
      5.  What are the architectural trends that might impact your application now or after it has been deployed？
         1. 未來的架構或技術趨勢，是否會影響到系統，或是部署方式
            1. 例如layer to tier，例如client/server to Web，例如Web to 雲端
   6. Architecture should
      1.  Expose the structure of the system but hide the implementation details.
         1. 系統架構圖，但避免落入實作細節
      2.  Realize all of the use cases and scenarios.
         1. 畫出Use Case Diagram and Activity Diagram
      3.  Try to address the requirements of various stakeholders.
         1. 定義出不同角色的需求
      4.  Handle both functional and quality requirements.
         1. 功能需求與品質需求都要兼顧
            1. 寫出來完全符合使用者的功能，但按一個鈕要跑五分鐘
   7. Architectural landscape key trends
      1. User empowerment
         1. 繪製出Use Case Diagram並確保scenario簡單明瞭
      2. Market maturity
         1. 避免重新發明輪子，站在巨人肩膀上，使用已經成熟的pattern解決常見的問題。才能focus在實際有價值的部分
      3. Flexible design
         1. loose coupling設計來增加重用性與可維護性，例如Dependency Injection
         2. SOA等service oriented的方式，增加與其他系統的互動
         3. Pluggable designs allow you to provide post-deployment extensibility.
      4. Future trends
         1. 例如RIA、網路頻寬的增加、手機等行動平台、硬體效能、形式(社群網路、微網誌)、雲端等等
   8. Principles of architecture design
      1. 哪一個部分是做錯時，可能導致最大的風險
      2. 哪部分是user最想改變的部分?哪部分delay了影響最小
      3. 關鍵假設是什麼?如何證明這個假設成立?
      4. 甚麼樣的情況下會需要重構或重新設計
      5. 應該把注意力集中在觀察，是否有需要重新設計的地方，應盡早發現且進行重構，避免修改成本過高
         1. 持續整合並且避免落入沒意義的追求完美
   9. Key Principles
      1. Build to change instead of building to last.
         1. 軟體開發過程中隨時可能需求改變，在設計架構時，應將這樣的彈性考慮進去
      2. Model to analyze and reduce risk
         1. 使用modeling tool and visualization tool，幫助自己掌握需求以及設計決策、分析影響的程度。不要拘泥於形式，而失去了capability
      3. Use models and visualizations as a communication and collaboration tool
         1. 透過models and visualization來降低溝通成本
      4. Identify key engineering decisions
         1. 訂出關鍵技術決策以及列出該area最常犯的錯誤出來
      5. 反覆改善架構，不要想一次就設計的完整。應該先設計出一個可以拿來測試與驗證假設的架構
         1. 先將大架構做對，在追求細節技術
         2. 避免一頭栽入細節，如table schema設計。或是做了錯誤的假設，導致致命的錯誤
   10. 時時該提醒自己的問題
       1. 做了哪些假設
       2. 有哪些明確與可能隱含的需求
       3. 這樣的架構設計，最大的風險為何?
       4. 風險減緩計畫
       5. 目前的這個架構比原本的架構或是上一個候選架構好在哪裡
2. Key Principles details
   1. Common application architecture
   2. Key design priciples
      1. Separation of concerns
         1. 盡可能的把系統上該提供的功能分開
            1. 透過modeling的方式，來達到高內聚低耦合的model
      2. Single Responsibility principle
         1. 切乾淨、獨立，每一模組或元件應只負責單一目的
      3. Principle of Least Knowledge
         1. 封裝原則，用的人不必知道物件內的細節或實作方式
      4. Don't repeat yourself (DRY)
         1. 避免重複，散落一地
            1. 基本上可透過Simian分析出來
      5. Minimize upfront design
         1. Only design what is necessary
            1. 除了不做可能會死的部分，可以先用點時間實作
      6. 降低複雜度的方式就是切開
         1. 例如切層，UI、BLL、DAL各司其職
   3. Design Practices
      1. the wide range of factors that can affect the ease of designing, implementing, deploying, testing, and maintaining your application
         1. Keep design patterns consistent within each layer
         2. Do not duplicate functionality within an application
            1. 高內聚設計，易於重構、最佳化、可維護性高，尤其在需求變更時
         3. Prefer composition to inheritance
            1. 繼承只有兩種用法，第一種是不用，第二種是很小心的使用
            2. 因為繼承會增加深度，且限制子類別的重用性
            3. 例如某一個子類別被父類別限制，但無法因這個CASE而修改父類別，因為子類別有很多。修改父類別，將影響其他繼承該父類別的子類別
      2. Establish a coding style and naming convention for development
         1. 程式可讀性
         2. Glossary
            1. 程式可讀性、一致性，溝通標準一致降低溝通成本
      3. Maintain system quality using automated QA techniques during development
         1. SourceMonitor & Unit Testing & Daily Build by CI
      4. Consider the operation of your application.
   4. Application Layer
      1. Separate the areas of concern
         1. 切層，讓功能overlap的程度降到最低
            1. 可獨立的最佳化、重構、以及因應需求變更的調整
            2. 增加系統可讀性，因為都是切開的部分都是獨立的
      2. Be explicit about how layers communicate with each other
         1. 明白的定義出layer之間如何傳遞資料
            1. 例如UI可透過domain object與service得到資料
            2. 例如不能跨層呼叫
            3. 但報表等特殊需求可以
      3. Use abstraction to implement loose coupling between layers
         1. 例如先定義好interface，明確的知道該提供哪些東西，才進行實作
      4. Do not mix different types of components in the same logical layer.
         1. 例如UI層不應該有太多的商業邏輯，應該著重在處理input與request，以及資料的呈現
      5. Keep the data format consistent within a layer or component.
         1. 例如民國年、西元年。
         2. 例如日期有datetime、varchar型態、NVarChar型態
         3. 例如單位千元、百元顯示
         4. 例如空字串與DBNull的定義
   5. Components, Modules, and Functions
      1. A component or an object should not rely on internal details of other components or objects
         1. 封裝物件後，物件裡面的實作細節，應避免依賴於其他物件的細節，(代表耦合性太高)
      2. Do not overload the functionality of a component
         1. 例如DB資料的連結透過UI的Control屬性就可以決定
            1. 物件越來越肥，越來越難維護，到處都客製化，就無法stable
      3. Understand how components will communicate with each other.
         1. 瞭解物件之間如何互動，如何傳遞訊息後完成需求
      4. Keep crosscutting code abstracted from the application business logic as far as possible
         1. 降低深度
         2. Crosscutting code refers to code related to security, communications, or operational management such as logging and instrumentation
         3. 混在一起的程式，會導致無法extend與maintain
      5. Define a clear contract for components
         1. 例如Domain object的Interface
         2. describe how other components can access the internal functionality
   6. Key Design Considerations
      1. 決定一堆東西
         1.  Determine the Application Type
         2.  Determine the Deployment Strategy
         3.  Determine the Appropriate Technologies
         4.  Determine the Quality Attributes
         5.  Determine the Crosscutting Concerns
3. 第一版的guide
   1. 1
   2. 2