壹位同事認為是優惠券端發送的，思路是這樣的，優惠券領取是否成功和優惠券的相關信息，比如金額、限制，是在優惠券端的，而且領取成功後，調用消息通知也是順的。其他的產品同事也認可這樣的方式。流程圖如下：
而我持的觀點為：發送短信應該是活動端進行調用的，而不是優惠券端，流程圖如下：
下面我就闡述壹下我的觀點。其實但就這個問題來講，壹個很核心的點就是優惠券和活動的對應關系。在我看來，優惠券和活動應該是多對壹的關系，也就是壹個活動會發送多張優惠券。
就比如滴滴活動時，會發送壹堆券給到用戶，去涵蓋比如打車、專車、拼車等多項業務，多種價格，就是很典型的多張優惠券對應壹個活動的形式。
假設發短信放到優惠券端，在優惠券領取成功之後，就會發送短信，那如果出現壹次性可以領取多張券的情況，就會出現用戶收到多條短信的情況，在整個用戶體驗和短信成本兩邊考慮都是不合適的。
而將短信的發送放到活動端時，就會很好的避免這個問題，當券領取成功後，統壹發壹條短信給到用戶，同時短信內容還可以根據活動進行自定義，不管是用戶體驗的角度還是短信成本的考慮，都是最合適的選擇。
就那上面的例子來看，對於優惠券來講，他的自身屬性就是限制和優惠金額。限制是使用的壹個限制，比如滴滴發的專車券，只能在預約專車服務，進行支付時使用。根據不同的業務和場景，限制有很多，比如平臺限制、業務限制、時間限制、金額等。優惠金額是指在使用時可以抵扣或者優惠的金額。壹般有固定金額和不固定金額。固定金額就是創建優惠券時，就設定的金額，比如滿減券，滿1000元減100元，也就是優惠券的金額是優惠100元。還有就是不固定金額，比如7折券，不確定具體的優惠金額，而是根據限制和具體使用時，進行確定。
對於活動來講，活動的自身屬性就是展示和推廣。展現主要是活動的展現形式，包括產品等其他信息。推廣主要是比如領券、分享等。
也就是從短信來看，應該屬於活動的推廣部分，因此應該是從活動這邊進行發送。
那麽，根據產品的功能邊界去設計產品，有什麽好處呢？
從產品的角度來看，功能應該是獨立和模塊化的，產品只是根據業務和用戶體驗，在不同的頁面，拼接不同的功能模塊，從而達到產品體驗的最大化，同時使產品富有靈活性和可擴展性的特性。
我常常具這樣的例子，產品的功能就如同樂高壹塊塊獨立的積木，而產品就是通過不同積木組合，依據業務需求和產品經理的壹點奇思妙想，拼出來的模型。而積木與積木之前拼合在壹起的只是那簡單的幾個卡扣而已。壹旦某壹塊積木出現問題或需要調整，只需要動到那壹塊積木和與之相連的即可。
通過借助產品的功能邊界，去設計功能，從產品金字塔最低端的細小功能點壹點點去設計，到後來功能塊、功能、頁面，乃至整個產品，看似是個完整的整體，其實裏面又獨立者大大小小的個體，通過個體與個體之間的獨立又緊密配合，來達到整體的配合，無疑這是最完美的情況。
如果將功能按照功能邊界的思維進行拆分和整合，妳會發現，當妳再做另個產品時，可能只需要對功能模塊進行重新排列，就可實現了。如果壹個需求到了這邊，妳也會能夠準確的分析出，涉及到的功能點和影響範圍，從而更輕松的應對需求，實現更好的產品叠代。