7
Obecnie jestem w trakcie projektowania aplikacji opartej na mikroserwisach Node.js i chciałbym skorzystać z Domain Driven Design jako wytycznych wytycznej do struktury poszczególnych usług . Mam kilka pytań na temat tego, co następuje:Domain Driven Design dla Node.js
- O ile mi zrozumieć, warstwa domeny powinna zazwyczaj zawierają interfejsy repozytorium, a konkretne implementacje tych interfejsów należy następnie utworzony w warstwie infrastruktury. Spowoduje to usunięcie podstawowych problemów związanych z pamięcią masową/techniczną z twojej warstwy domeny. W kontekście mojego projektu, widząc jak JavaScript nie wspierają rzeczy takich jak interfejsy, jak można by osiągnąć podobny efekt?
- W szczególności jedną z usług będzie obsługa uwierzytelniania za pomocą protokołu OAuth. Czy zwykle klasyfikuje się logikę związaną z OAuth jako usługę aplikacji? A może wpadłoby w warstwę infrastruktury? Rozumiem, że nie jest to związane z infrastrukturą, ani nie jest powiązane z domeną podstawową, ale nadal jest wymagane w ramach obsługi aplikacji dla klientów. Dlatego umieściłem go na razie w warstwie aplikacji.
- Kontynuując od punktu 2, gdzie najlepiej umieścić jednostki powiązane z OAuth/repozytoria (tj. Tokeny/klientów)? Mam ochotę trzymać je w warstwie domeny wraz z moimi innymi jednostkami/repozytoriami, mimo że nie są one technicznie problemem biznesowym.
Kilka uwag, aby dodać do powyższego:
- jestem nie chętni do korzystania maszynopis (jak sugeruje here).
- Jestem w pełni świadomy, że niektórzy mogą uznać JavaScript za nieodpowiedni dla podejść typu DDD. Znam niektóre z pułapek i ponownie używam DDD jako wskazówki.
Na marginesie, mam wymyślić następującej struktury projektu, który był mocno zainspirowany this doskonały przykład projektu DDD opartym na laravel:
app/
----app.js
----package.json
----lib/
--------app/
------------service/
----------------oauth.js
----------------todo.js
--------domain/
------------list/
----------------model.js
----------------repository.js
----------------service.js
------------task/
----------------model.js
----------------repository.js
----------------service.php
--------http/
------------controller/
----------------list.js
----------------task.js
------------middleware/
----------------auth.js
----------------error.js
--------infrastructure/
------------db.js
------------logger.js
------------email.js
chciałbym usłyszeć wszelkie myśli, które możesz mieć na temat tego układu. W pełni zdaję sobie sprawę, że temat struktury projektu jest w pewnym stopniu oparty na opiniach, ale zawsze chętnie słucham, co inni mają do powiedzenia.
Czy myślisz, że projekt DDD mówi Ci, jakie nazwy musisz wybrać dla podkatalogów, które będą używane w twoim projekcie? Niewiele, o czym wiem, brzmi, jakby nie na takim poziomie szczegółowości.Wygląda na to, że chodzi bardziej o to, abyś zaprojektował logikę modelu biznesowego w jednym miejscu i zachował wszystkie inne elementy pomocnicze (jak na przykład autoryzacja użytkownika i inne zwykłe elementy infrastruktury), ale nie ma to nic wspólnego z rzeczywistą logiką biznesową. w miłym wygodnym, osobnym miejscu. – jfriend00
@ jfriend00 całkowicie się zgadzam. To jest, moim zdaniem, główny napęd DDD - budowanie wokół "podstawowej domeny biznesowej". Być może dla wyjaśnienia, będę edytować mój post, aby podkreślić fakt, że nie jestem zbyt skoncentrowany na strukturze/nazewnictwie, bardziej na zapewnieniu prawidłowej klasyfikacji/separacji. –
Ale twoje całe pytanie brzmi, jakby chodziło o to, w jakie katalogi umieścić rzeczy, a nie o to, co w twojej aplikacji jest podstawową logiką biznesową i jak można ją zorganizować niezależnie od wszystkiego innego. Szczerze mówiąc, tam, gdzie wszystko inne idzie nie jest tak ważne (np. Co to jest usługa i jaka jest infrastruktura). Są to tylko etykiety, które należy wybrać, aby uczynić układ projektu przejrzystym dla innych i wygodnym w użyciu. – jfriend00