說些個人的感受和淺見。
程式碼是承擔業務的，而service層承擔了業務的最主要的部分。向上提供介面，向下依賴第三方和資料庫儲存。
MVC中service層是用來承擔業務功能的主要部分，你所說的“隨著需求不斷變多變複雜，Service裡的內容越來越多”，需要找下原因，如果確實需求複雜了，需要那麼多的程式碼，還會有什麼不正常嗎？
而不正常的情況，或者實際情況往往是，經過一段時間，很多程式碼已經是每個語句都能看懂，連起來卻看不懂了。一句話概括就是，程式碼不再反映業務的邏輯和含義了。
造成的原因。我見過的情況是糙快猛的迭代，設計的缺乏。比如來了個新功能的需求，老的程式碼有點不相容怎麼辦？一幫人八仙過海、絞盡腦汁地想要得到一個少（不）改老程式碼，實現新功能的方案，還很有理由：對老業務保證沒影響，工作量還不大。背後的邏輯是：程式碼是規則，程式碼沒有生命，只需要讓規則跑通就完事了。事實往往是，為了少寫幾行程式碼，耗費了腦力做無用功，讓專案逐漸地很難維護，不敢維護，不可維護，程式碼表達業務的生命力被拋棄，還談什麼程式碼質量。更常見的情況是，專案開發過程中，沒有溝通，各做各的，幾個人完全按照自己的理解拼湊出一個專案。
解決的思路。分層背後的邏輯是關注點分離，隔離了不同邏輯，也就讓不同部分的程式碼代表了不同的業務含義。但是分層僅僅是技術角度去考慮的，總不能每次來個需求就加一層吧？領域模型是從業務角度出發的，程式碼反映業務，業務變化怎麼辦？程式碼跟著業務變就行了。所以我同意提問中的加入領域模型，但是不太同意認為這種做法是引入更多的層。哪會有引入很多的層呢？只引入了一個領域層而已，甚至都不需要引入，service層也可以作為領域層。
說些個人的感受和淺見。
程式碼是承擔業務的，而service層承擔了業務的最主要的部分。向上提供介面，向下依賴第三方和資料庫儲存。
MVC中service層是用來承擔業務功能的主要部分，你所說的“隨著需求不斷變多變複雜，Service裡的內容越來越多”，需要找下原因，如果確實需求複雜了，需要那麼多的程式碼，還會有什麼不正常嗎？
而不正常的情況，或者實際情況往往是，經過一段時間，很多程式碼已經是每個語句都能看懂，連起來卻看不懂了。一句話概括就是，程式碼不再反映業務的邏輯和含義了。
造成的原因。我見過的情況是糙快猛的迭代，設計的缺乏。比如來了個新功能的需求，老的程式碼有點不相容怎麼辦？一幫人八仙過海、絞盡腦汁地想要得到一個少（不）改老程式碼，實現新功能的方案，還很有理由：對老業務保證沒影響，工作量還不大。背後的邏輯是：程式碼是規則，程式碼沒有生命，只需要讓規則跑通就完事了。事實往往是，為了少寫幾行程式碼，耗費了腦力做無用功，讓專案逐漸地很難維護，不敢維護，不可維護，程式碼表達業務的生命力被拋棄，還談什麼程式碼質量。更常見的情況是，專案開發過程中，沒有溝通，各做各的，幾個人完全按照自己的理解拼湊出一個專案。
解決的思路。分層背後的邏輯是關注點分離，隔離了不同邏輯，也就讓不同部分的程式碼代表了不同的業務含義。但是分層僅僅是技術角度去考慮的，總不能每次來個需求就加一層吧？領域模型是從業務角度出發的，程式碼反映業務，業務變化怎麼辦？程式碼跟著業務變就行了。所以我同意提問中的加入領域模型，但是不太同意認為這種做法是引入更多的層。哪會有引入很多的層呢？只引入了一個領域層而已，甚至都不需要引入，service層也可以作為領域層。