W ogóle ja mam wrażenie, że jak coś czytam/słucham o DDD na konferencji, czy z książki, niech to będzie Eric Evans choćby, a jak widzę realny kod, który jest "pisany w DDD", to jest niebo a ziemia. Tak jakby teoria się rozmijała z praktyką.
Ale nie, nie winię gurusów DDD czy DDD jako takiego, tylko winię ludzi, którzy wcielają w życie DDD nie rozumiejąc przesłania.
Już sam fakt, że ludzie próbują "pisać w DDD" przesądza o tym, że będzie to kupa gówna, bo ludzie po prostu pakują randomowo wzorce opisane w książkach do DDD, zamiast spojrzeć szerzej. Zaryzykowałbym opinię, że DDD bez tych wszystkich wzorców (czyli DDD bez encji, bez agregatów, bez repozytoriów itp.) dalej miałoby sens (ludzie zdają się zapominać, że DDD znaczy Domain Driven Development a nie Design Pattern Driven Development. Wtedy byłoby to DPDD). Owszem, jakieś wzorce (czy raczej "building blocks", jak to zostało opisane w książce Evansa) są być może potrzebne. Rzecz w tym, że jeśli nie te wzorce, to zawsze można wymyśleć inne.
Tak samo wzorce projektowe kojarzone zwykle z DDD można stosować również bez DDD. Przecież nazwanie klasy Entity
nie oznacza wcale, że będzie to zgodne z duchem DDD. Szczególnie, że z DDD kojarzy się również wzorce, które nawet nie były chyba pierwotnie traktowane jak część DDD - CQRS, event sourcing... (w każdym razie pewno stosowanie tych wzorców nie oznacza, że coś będzie zgodne z duchem "domain driven design").
Sam nie uważam się za żadnego speca od DDD, jednak szkoda w sumie, że idea, która miała pewien potencjał (tak jak Agile choćby) zostaje zamieniona w jakiś ogromny cargo cult i bezmyślne kopiowanie modnych wzorców (co do Agile, to takim wypaczeniem i parodią Agile, stał się oczywiście Scrum, który jest w pewnym sensie zaprzeczeniem całego Agile - bo jeśli się tworzy gotowy framework do tego, "jak być zwinnym", to automatycznie przestaje być się zwinnym, jeśli się po prostu postępuje zgodnie z góry wyznaczonymi procedurami).
Shalom