黃康銳
題主沒有說明具體的應用場景。拿Java開發Web後臺服務為例，常用的是三層或者多層架構，業務邏輯和控制層、數據層分離解耦。
一，系統架構
隨著應用系統功能日趨複雜，前後端動靜分離架構使用越來越普遍，前端負責用戶交互，後端負責業務邏輯處理。對於複雜耗時任務，經常引入異步任務調度系統，比如Quartz和ActiveMQ消息隊列。
二，後臺服務架構
後端開發常用Java + Spring Boot框架，開發Web服務時，有Controller，Service，Entity，分別封裝接口、業務邏輯、數據。
三，業務邏輯實現
在Controller封裝服務接口時，調用Service實現業務邏輯。以LogController為例，為前端提供接口/log，被調用時記錄重要的用戶操作。
在接口實現函數log()中，調用LogService讀寫數據庫，生成描述信息，過濾重複數據，然後寫入數據庫，實現業務功能。
單元測試重點覆蓋這些業務邏輯函數，保障代碼和項目質量。
我是工作多年的Web應用架構師，陸續發佈關於軟件開發方面的文章，歡迎關注我，瞭解更多IT專業知識。
急速馬力快de源碼控
現在很多公司開發人員應該採用都是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，方法名自取，此處只是拋磚引玉，不做過多的介紹。
結束語
經過問題的分析和解答，我想題主應該知道該怎麼去寫業務邏輯了，請記住，不管什麼情況下，我們要學會以不變應萬變，一般來說按照框架規範來寫不會有錯，特殊情況可自行拓展。
