我在想，方法名和它們的調用似乎會在代碼中創建一個DSL，通過包裝通用的東西併爲您要實現的目標進行適當的命名。請仔細考慮方法/函數名稱創建一個DSL？
你知道的，所以很容易推理一下以下方法
if (a.isSubReportOf(b) || b.isSubReportOf(a)) {
// do stuff
}
，但這些方法的代碼也許真的很難，不研究它來解釋。
我知道人們有時會認爲對於整個DSL來說有一些特殊的東西 - 我們是否一直在代碼中創建它們？
我想你是指Martin Fowler（也可能是其他人）稱之爲內部DSL。閱讀this。
你可以交替詢問DSL是否應該用經過深思熟慮的類，變量和方法名稱替換。我一直將這一點與Kent Beck聯繫在一起，因爲他一直是「編寫像詩歌一樣的代碼」的支持者。
你是發明了領域詞彙表，將商業操作的語法制作成對象，方法和變量。聽起來DSL'ish;）
這取決於你的DSL的定義，但對我來說，是的，我會這麼說。 DDD的全部內容都是創建抽象概念，使您能夠在更高層次上獲得無處不在的語言和理念。有人可能會認爲它不是一個DSL本身，但更重要的問題是，代碼就像這個域的推理一樣？
我會說是，那纔是真正重要的。
你可以用一個足夠複雜或簡單的情況來替換另一個嗎？是
它們是否一樣？一點也不。
每個人都有優點和缺點，這一切都取決於需要什麼。如果你需要它在運行時是可以修改的，那麼以編譯語言使用函數可能不是最好的解決方案（但它仍然可能），因爲它會對你的需求太重。
DSL的目標是精確定位您的需求，並制定一種只包含這些需求的語言，以便儘可能簡單地表示。這樣，我們有限的大腦可以輕鬆地描繪出數據的內容，而無需編譯程序。
此外，一個足夠簡單的DSL可以很容易地被另一個程序解析和編輯。畢竟，你製作了語法，並將其封裝在一個庫中，對吧？
在你上面的例子：
a.isSubReportOf(b) || b.isSubReportOf(a)
仍難以把握精神比說：
a <-> b