Tight coupling - jak uniknąć?

Cześć,
do tej pory we wszystkich swoich projektach używałem nieświadomie podejścia "encja na twarz i pchasz" : ) - czyli używałem jednej klasy do selectów, dodawania/edycji i do bindowania pod widoki (WPF). Obejrzałem film "Architektura to nie bzdura":

I mam pytanie - czy dobrze to zrozumiałem? Na przykładzie klienta i WPF:

1. Tworzę klasę Customer, której używam tylko w EfCorze - jako np. DbSety
2. W metodach typu GetCustomers zwracam klasę CustomerDto, która jest read-only (?) i zawiera wszystkie właściwości, co encja (np. FirstName, LastName, Email), ale bez np. StatusId
3. Do bindowania pod dialogi tworzę klasę CustomerBo (Bo = Business Object), która ma wszystkie pola co encja (+ np. IsSelected), ale bez odwróconych relacji (tzn. w przypadku relacji many-to-many UserBo ma właściwość List<Privilege>, ale PrivilegeBo nie ma już List<User>, mimo że encja Privilege je posiada). Obiekty biznesowe przekazuję jako parametr w metodach typu AddCustomer(), UpdateCustomer()?

Niepokoi mnie trochę to, że muszę stworzyć aż trzy klasy do jednego obiektu w aplikacji. I jak powinno wyglądać rzutowanie? Czy CustomerDto i CustomerBo powinien mieć w konstruktorze przekazywaną encję i tworzyć tam konwersję?

I jak z nazewnictwem i przechowywaniem? Czy wszystko idzie do folderu Models?

Z sufixem Bo się nie spotkałem. Chyba wolę podejście z oddzielnymi klasami do różnych rodzajów requesta AddCustomerDto, EditCustomerDto, GetCustomerDto, AddCustomerAddessDto etc. (CQRS?). Do widoku to chyba też wystarczy CustomerViewModel. Jak masz wyświetlanie i edycję na jednym widoku to można z tego zrobić akcję EditCustomerFromViewModelDto albo coś takiego. Ale nie pracowałem z WPF, ani nie ogladałem filmiku jak coś.

widzę że jeszcze nie nabrałeś złych nawyków
zmień język tylko na jaki? w PHP też widziałam coś podobnego, okraszone klasami javascriptowymi w dodatku
w javie też
może w pythonie się nie da robić czegoś takiego
Bo wbrew całemu piiiiik że to architektura i w ogóle jak krytykujesz to masz wszy i jesteś ruska onuca to taki kod ma za zadanie:

• dowalić więcej kodu do projektu żeby było widać że programista w pocie czoła pracuje
• namieszać żeby nikt inny się w tym łatwo nie mógł połapać
• zapewnić se dużo roboty typu copy&paste z jednego pliku do drugiego

Mam nadzieję że w końcu przyjdzie bazodanowiec i wyrzuci z tego lasu Niemców i partyzantów ;)