黃康銳
這是一個非常好的問題，很多Java初學者都會面臨類似的問題，作為一名從業多年的IT人，同時也出版過Java編程書籍，所以我來回答一下這個問題。
首先，Java語言的抽象程度是比較高的，在進行程序開發的過程中，通常會為Java代碼按照不同的抽象程度進行模塊劃分，這個過程對於程序員的開發和設計能力有比較大的考驗，抽象不足或者是抽象過度都會導致一定的問題。實際上，為了解決抽象設計和模塊化問題，Java開發人員通常會採用各種開發框架（Spring、OSGI等），這也是為什麼學習Java通常都需要學習框架的一個重要原因。
如果從單獨的功能模塊劃分角度來看，Java代碼可以分為數據部分、控制部分和呈現部分，也就是比較經典的MVC結構，其中業務邏輯就可以放在控制層，早期的設計方案也會把一部分業務邏輯集中在模型部分。實際上，在當前微服務概念的推動下，抽象程度也得到了一定的提升，結合雲計算服務（PaaS），很多業務邏輯可以進行獨立設計，而當前業務中臺和數據中臺本身就是單獨設計的，各自都有相應的側重點。
對於擴展要求比較高的系統來說，把業務邏輯抽象出來，與控制層和數據層進行解耦也會獲得更大的靈活性，複用程度也會比較高，而且在進行技術平臺遷移時會更方便一些。實際上，Java開發從早期的Struts向Spring過渡的過程中，就在一定程度上提升了代碼的複用性和擴展性。
最後，在定義Java業務邏輯位置的時候，一定要考慮到容器（Container）的問題，通常業務邏輯可以通過多線程的方式來提升執行效率，而實體組件（Bean）則通過容器來提升效率。
我從事互聯網行業多年，目前也在帶計算機專業的研究生，主要的研究方向集中在大數據和人工智能領域，我會陸續寫一些關於互聯網技術方面的文章，感興趣的朋友可以關注我，相信一定會有所收穫。
如果有互聯網、大數據、人工智能等方面的問題，或者是考研方面的問題，都可以在評論區留言，或者私信我！
IT人劉俊明
現在很多公司開發人員應該採用都是mvc架構。
Mvc就是所謂的model模型，view視圖，controller控制器。
每個層都有明確分工。
簡單的項目拋開nignx，網關，一般都是前端發一個請求到後端，首先到達contoller然後是service層再然後是dao層。
這裡的service層就是所謂的業務層，專門負責業務處理操作，而dao層負責和數據庫打交道，從db拿數據返給service，sevice處理完返給controller層，controller通過視圖解析器，解析完通過瀏覽器渲染頁面。
說到這裡基本上，我想答案已經很明顯了。那就是Java業務邏輯寫在service層。
而sevice層其實又涉及到接口和接口實現。
就是我們一般寫代碼都會定義一個接口供controller去調用。
其實service接口的實現類最終才應該是寫業務邏輯的地方。
當然很多公司可能不止一個sevice層，比如還有一個manager層繼續對數據做特殊業務處理，這裡只是簡單的說下大致情況。
每個公司每個項目根據自身業務，架構可能不太一樣。但本質是一樣的。
總結一下就是業務邏輯肯定需要單獨作為一層去處理，這樣既方便拓展，也方便維護。切記不要把所有的業務邏輯都寫在controller裡面。
每個層都有自己的分工，都揉在一塊不僅僅代碼冗長看起來還很亂，不清晰。
好了，希望我的回答能幫到你！
感興趣可以關注，共同學習交流！
碼農的搬磚生涯
從問答來看，我揣測題主應該是一位 java 新手，因為老手已經很瀟灑地在規範好的目錄結構下擼碼了，所以對於這個問題，我想說的是：規範是死的，人是活的，一般情況下，我們可以根據不同的 java 框架規範的目錄來寫，特殊情況下也可以自定義。
問題分析
接觸過 java 的同學可能都知道，java早期是前後端全部包攬的，代碼也是比較臃腫，隨著時代的發展，也就開啟了前後端分離的趨勢，而 java 也就慢慢地淪為後端開發語言。
作為後端開發攻城獅，我們永遠繞不開的就是業務邏輯的問題，也許有人會說這個應該前端去管吧，其實差矣，前端要管，後端更要管，因為前端只是頁面上可見的邏輯，而後端是背後無形的邏輯，並且跟數據庫直接打交道，重中之重。
而 java 經過這麼多年的發展，也湧現出了大批優秀的框架，而不同的框架結構可能又不完全一樣，所以在我們確定在哪裡寫業務邏輯之前，我們先要確定好框架，因此問題的突破口就很明朗了：
1、確定好 java 開發框架
2、在選定框架的規範的目錄下寫業務邏輯（特殊情況除外）
解決方法
通過了問題分析，我想基本不用我講太多應該都知道怎麼做了，不過本著負責的態度，我還是繼續講完。
1、確定 java 框架
經過這麼多年發展，java的優秀框架很多，而我用過的有akka、springboot，不過現在還是在用springboot，因為akka實在有點難以操作，所以在此不推薦新手，也不做介紹，有興趣的可以自己去查一下資料，而至於為啥推薦springboot，是因為它真的比較簡潔，很適合新手，也很方便老手。
2、規範目錄結構
在我們確定好 springboot 框架之後，我們可以先來看一下一般的規範目錄結構是怎樣的，如下圖所示：
從圖可知，我們一般的業務邏輯都會在controller裡面去寫，當然這個不是固定的，有時候如果有類似的業務，我們還可以把相同的地方抽離出來，單獨寫在另外的地方，比如common目錄下或自己新建的目錄下。
3、實例說明
我們可以在剛剛的controller目錄下新建一個
TestController.java
的文件，然後編寫代碼如下：
這個只是一個簡單的模板，具體的業務邏輯1可以寫在work裡，如果還有別的業務邏輯2，那就再弄一個work2，方法名自取，此處只是拋磚引玉，不做過多的介紹。
結束語
經過問題的分析和解答，我想題主應該知道該怎麼去寫業務邏輯了，請記住，不管什麼情況下，我們要學會以不變應萬變，一般來說按照框架規範來寫不會有錯，特殊情況可自行拓展。
