Nie twierdzę, że DDD wprowadza luźne sprzężenie i napewno nikogo nie będe do tego przekonywać. Wprowadzenie warstw w każdym przypadku zmniejsza sprzężenie, dlatego, że warstwy wymuszają jednokierunkową komunikację i definują spójne ze sobą elementy aplikacji. Dlatego też nie śmiem twierdzić, że wyżej przedstawione rozwiązanie nie jest luźno sprzężone.

Opisany przez ciebie schemat architektury w dużej mierze pokrywa się z założeniami DDD i w pełni z tobą się zgodze, że w większosći przypadków rozwiązanie to będzie się lepiej sprawowało. Mimo to często spotykam się z stosowaniem architektury przedstawionej w poście, dlatego też nazwałem ją klasyczną. Z kontekstu twojego komentarza uważam teraz że wybrana przeze mnie nazwa -”klasycznej” architektury jest z leksza chybiona.

„Co więcej, te zasady są o wiele starsze niż pojęcie “Domain Driven-Design”, które ostatnio jest tak popularne.”

Zgadzam się z tobą. Warto zwrócić uwagę, że większość rozwiązań w DDD to nic nowego, tylko utrwalenie wcześniej już znanych aspektów programowania obiektowego.

Pozostałe warstwy są zależne tylko od BLL/Domain. Gdy potrzebna jest osobna relacja stosuje się DIP (Dependency Inversion Principle) i wszystko gra…

Co więcej, te zasady są o wiele starsze niż pojęcie „Domain Driven-Design”, które ostatnio jest tak popularne.

W sumie nie wiem co będzie w drugiej części posta, ale mam nadzieję, że nie będziesz sugerował, że „luźne wiązanie” (loose coupling) jest wykorzystywane tylko w DomainDrivenDesign, a w „zwykłym programowaniu” (standardowych 3/4/5 warstwowych aplikacjach) już nie.

Dziękujemy za publikację – Trackback z dotnetomaniak.pl…