sklep internetowy oraz blog rozdzielam jako różne app's. <- tak, możesz. w zasadzie pewnie powstanie ci troszkę więcej appsów. Ja osobiście bym rozdzialił to raczej na dwa oddzielne projekty djangowe - jeden ze sklepem, drugi z blogiem. A w appsach jeszcze mniejsze moduły, np. w sklepie coś jak "users", "orders", "invetory" i tak dalej. Ogólnie jak zrobisz cały sklep jako jedną appkę będącą częścią projektu tylko, to może się okazać, że bardzo ci ona spuchnie i ciężko się będzie odnaleźć w kodzie. Nie bój się dzielić rzeczy na mniejsze klocuszki.
Często spotkałem się, że jako oddzielne app buduje się system logowania - nazwijmy je "accounts". Tu buduję swoje widoki, modele odpowiedzialne za logowanie, rejestrację. tak, autentykacja i autoryzacja to zazwyczaj osobna appka. Przy czym polecam ci, byś sam nie wymyślał tutaj koła na nowo, zwłaszcza jak o security idzie, i skorzystał z gotowców wbudowanych w django. Pisząc samemu od postaw system autoryzacji/autentykacji istnieje 99,9% szansy na to, że coś grubo popsujesz. Więc twoja appka accounts czu też users, jak nazwiesz, bez różnicy, powinna być tylko lekką nakładką na auth z django.
W takim przypadku powinienem stworzyć 3 apps: jak napisałem wyżej - ja bym to bardziej rozbił na dwa projekty złożone z wielu appek. Ilu? Trudno powiedzieć, zależy od requirementsów.
Czy taka praktyka jest prawidłowa? - tutaj moim zdaniem upchniesz za dużo rzeczy odpowiedzialnych za różne funkcjonalności w jedną appke typu shop, spróbuj zaprojektować swój kod tak, by był on w miarę logicznie podzielony na małe paczuszki/fragmenty (appki), które odpowiadają za jakiś konkretny fragment funkcjonalności.
zamiast budować aplikacje w czystym Django mikroserwisik też możesz napisać w czystym django bez użycia django templates. DRF to tylko nakładka, która to ułatiwa. Nic nie stoi na przeszkodzie robienia RESTowych API za pomocą czystego Django.
I teraz moje pytanie - jak buduje się tego typu aplikacje? Jak wykorzystuje się DRF? Jak oddziela back- od front-end? <- zazwyczaj dzieli się je na wiele małych klocuszków. Dlaczego? Zamykasz pewną funkcjonalność, pewien kontekst i logikę biznesową, w jednym jakimś miejscu. To tam jest, jest do ogarnięcia. Jeśli wszystko jest wymieszane razem, czasem trudno to ogarnąć i robi się bałaganik.
Co do pytania - jak się je buduje... Cóż, książkę można by o tym napisać. W zasadzie kilka. Kilkadziesiąt, kilkaset w sumie. Ludzie dalej nie są do końca tego pewni i dalej powstają badania, książki, publikacje, zgłębiająće ten temat.
Jedno jest pewne, obecnie mamy tak wysoki poziom specjalizacji, że fronty są kompletnie oddzielne (często teraz nawet front się dzieli - jest gość od html/css, jest gość od reacta, jest gość o czystego jsa) - zazwyczaj to jakaś aplikacja napisana w react, która korzysta z backendowego restowego api. Oprócz frontu, backendu, zazwyczaj mamy też osoby odpowiedzialne za projekty interfejsu graficznego - tego co widzi użytkownik, tego jak to ma działać - UX ogółem, OPSi, zajmujący się infrastrukturą, admini. Ogółem przy dużych appkach ten podział pracy jest bardzo wyspecjalizowany.
Pod przykrywką api może się czaić wiele serwisów skupionych w jednym gatewayu, albo i nie - front może korzystać jednocześnie z wielu api. Temat rzeka ogółem.
DRF wykorzystuje się do budowy restowych api z użyciem django - tak po prostu. Ułatwia i rzyśpiesza on pracę. Wszystko, co zrobisz w drfie, możesz oczywiście też naklepać sam w gołym django, ale to bez sensu - wymyślanie koła na nowo.
Front od backendu jest oddzielany tak, że to po prostu dwie różne aplikacje, dwa różne repo, dwa rózne codebasy. Zazwyczaj. Oczywiście można wszystko nasrać w jednym repo, da się, ale... ;)
Nie wiem cóż ci mogę więcej napisać.
Django 
Python 
Django Rest-Framework 