連接: 其他描述源
實現(xiàn)案例1: github鏈接
1饭寺，事件是對系統(tǒng)產生了業(yè)務上的影響的動作，相對的娶桦，如果僅僅是數(shù)據(jù)查詢操作双炕，則只會對系統(tǒng)產生技術上的影響狞悲，如CPU上升或者內存上升等
2，Event不一定由前面所說的某個Actor觸發(fā)Command而產生妇斤，也可能是由外部系統(tǒng)或者某種規(guī)則自動觸發(fā)Command而產生
3摇锋，某個Actor做出決策Command的前提是需要看到某些信息丹拯，或者說，支撐Actor更容易做出決策命令Command的信息乱投。讀模型一般是通過Web頁面（UI/UX）來展示更多的信息咽笼，以讓用戶更容易做出決策
4，“部門“墻 - Organizational silos
“部門”可以是公司行政規(guī)定的部門戚炫，也可以是虛擬的組織或者團隊剑刑。部門是最小職責范圍劃分的具象化，能讓每個人更快的知道自己工作的邊界并為公司做出貢獻双肤。
凡是企業(yè)施掏，幾乎必然有部門，凡是研發(fā)活動茅糜，幾乎都會涉及到跨部門協(xié)作七芭，凡是跨部門協(xié)作，必然會增加溝通成本蔑赘，這種溝通成本是所有企業(yè)研發(fā)最大的隱形投入狸驳。
每個部門都會認為自己運行的良好，總是對其他部門的工作充滿猜想缩赛，看不到整體耙箍，并且在事情或者項目上總是缺乏真正的對齊，只有自認為的達成一致酥馍。
- 如果相關的stakeholder不了解全貌辩昆，會更傾向于拖延而不是積極行動
- 難以達成共識，特別是跨部門之間旨袒，達成的共識更主觀汁针，并可能是錯誤的，會讓某些人誤以為是故意為之砚尽，產生隱形斗爭問題
- 企業(yè)架構的混亂施无。如果架構師不能了解全貌，則無法做出良好的架構決策尉辑，也不知道何時應該復用企業(yè)已有的技術能力帆精，長期的割裂會造成企業(yè)架構的混亂。
5隧魄，自組織團隊與決策
如果團隊無法理解整個系統(tǒng)，則不可能自組織隘蝎，如果系統(tǒng)或者需求的決策不是透明的购啄，不是去中心化的，則團隊不可能自組織嘱么，比如：
- 高層集中式決定并突然公布
- 與各個stakeholders單獨商量修改狮含，并公布給其他人
6，驕傲的專家
技術人員天然就會有意無意的“鄙視”業(yè)務人員。
他們和業(yè)務人員溝通時几迄，會不自覺或無意的暗示自己的專業(yè)能力蔚龙，他們喜歡技術能力強的感覺。很多時候這會造成隱形的溝通障礙映胁，因為溝通的一方會不時的陷入自我陶醉木羹，而不是在真正解決業(yè)務問題。
7解孙，軟件研發(fā)就是學習
現(xiàn)實情況是坑填，工程師需要花大量時間來搞明白他們到底要做什么，大多數(shù)情況下弛姜，他們都是第一次接觸某個業(yè)務脐瑰，這是一個學習的過程，而且不是他們擅長的技術領域廷臼。
對于工程師來說苍在，業(yè)務學習是最容易忽略且不被看重的，甚至還有點不屑荠商。
然而忽略業(yè)務學習寂恬，只關注技術學習，基本就是在浪費資源结啼，是假裝在解決一個很可能不會帶來任何業(yè)務價值的問題掠剑，典型的現(xiàn)象是：沒有清晰需求的情況下就開始寫代碼。
學習的過程肯定是累且不舒服的郊愧，如果感覺輕松朴译，那很可能是在進行無效的學習（定義和解決一個自以為是的需求）。
學習的動力來自于探索的好奇心以及成就感（比如嘗試用數(shù)據(jù)模型來表示問題空間属铁，以便解決比原來的問題更多問題的成就感）眠寿，業(yè)務建模是進行探索式業(yè)務學習的一種有效方式。
8焦蘑，軟件研發(fā)不僅僅是寫代碼
不同的人對上面這句話理解不同盯拱，從資深工程師的角度來看，寫代碼只占軟件研發(fā)的一部分例嘱，寫代碼之前還有設計狡逢，還有上線與運維；
從業(yè)務的角度來看拼卵，軟件研發(fā)就是寫代碼奢浑；
從老板的角度來看，特別是不懂技術的老板腋腮，軟件研發(fā)肯定就是寫代碼雀彼。這里的問題是壤蚜，如何讓相關的人都知道全局，知道除了寫代碼還有其他哪些工作要做徊哑。
現(xiàn)實情況是袜刷，在企業(yè)軟件中的整個生命周期中，維護（運維莺丑、運營）成本以及軟件需求調整/增加的成本才是大頭著蟹，而不是將軟件開發(fā)出來上線。
如果前期需求不清晰窒盐，那么就會極大的增加后期需求調整的成本草则，造成整體成本的增加。如果需求沒有和干系人對齊蟹漓，就不能說需求是清晰的炕横。
