問題領域與解決方案領域下篇 | Problem & Solution Domain
客戶與開發者的理解，圖片來源
複習前篇
在前篇中 ，澄清了問題領域是什麼、解決什麼情境、以及關注問題領域帶來的好處，而問題領域是接近並十分依賴客戶以及用戶端 ，而在接下來的解決方法領域則是開發者使用技術來解決問題。
解決方案領域 | Solution Domain
“ 解決方案空間包括任何由客戶使用或意圖供客戶使用的產品或產品表現形式。它與空白狀態相反。當你打造一個產品時,你已經選擇了一種特定的實現方式。無論你是否明確地這樣做,你都已經決定了產品的外觀、功能和運作方式。 ”
釐清問題領域並獲得釐清過程中的圖或文字敘述後，問題領域的迷霧散盡，一切都變得清晰。
但還有要釐清的東西，才能開始撰寫程式碼，也就是設計方面的問題，沒有設計過會導致能跑就好的心態，因此需要先進行設計。
如何設計解決方案 ?
在問題領域中，了解產品的功能以及非功能性的要求，例如像 FURPS+，在解決方案領域要考慮的是，如何達成並兼顧系統品質?
使用高階的描述方式，不涉及具體的程式碼。在物件導向設計中同樣可以使用 UML 去做圖像化的澄清，要注意的是，此時的描述相較於問題領域，更加貼近開發者，這意味著需要普遍的著重在功能的效率、彈性、可擴充性、可讀性、等等系統品質。
因此在問題領域釐清用例以及其脈絡的情況下，就是 GRASP、SOLID、設計模式 (Design Pattern )、CQS、KISS、Dry、演算法、架構等等... 出場的時候 。
獲得了什麼 ?
好的程式碼是可以作為解決方案的的同時也顧好系統品質。
問題領域給我們了迷宮的地圖與指南針，走出迷宮的方法有千百種，但我們要選一種效率更高、耗能最低的方法去走出迷宮，而方法就是解決方案領域給我們的
但要注意的是滿足系統品質通常代表著取捨，要如何在易擴充、可讀性、效能間取捨；要如何在一致性、可用性、分區容錯性兼做取捨；如何在開發效率以及程式碼品質兼做取捨等等...
作者心得
從需求到產品
從一個需求到確認功能的範圍、上下文，開發者用設計原則、架構、演算法去用另一個方式描述問題領域澄清的結構，最後依照解決方案領域的製品編寫程式碼，最後獲得了高品質並且貼近客戶想要的產品。 要注意的是這看起來很像線性的開發，但多數的時候解決方案領域的澄清有可能造成問題領域的改動， 因此問題領域與解決方案把需求到產品的過程更加細化的同時，也給予了迭代的調整的特性。
問題領域、解決方法領域雖然已經細化了從需求到程式碼的過程，但領域要做的事也是非常廣泛與深奧的，對我來說，雖然不知道一套方法，能夠完整將這兩個領域落實，但光了解這兩個領域的概念就已經可以更加明白甚麼是在與客戶的討論中需要明確的，什麼又是開發者可以自由發揮的。