@montmartre: Życie to nie rzeczywistość z książek Uncle Boba. Biznes w pierwszej kolejności ma zarabiać. Gdybyś był taki doświadczony jak piszesz to byś wiedział, że w DDD wyróżnia się poddziedziny (główne, wspierające i generyczne). I w zależności od tego w której poddziedzinie jesteśmy to używamy odpowiednich narzędzi by ją zamodelować i zaimplementować. Pewnie jesteś z tych co każdą aplikację piszą "jak należy".

A prawda jest taka, że wzorce taktyczne DDD, CQRS-yPokaż całość

@montmartre: No to nie wiem skąd twoje zdziwienie? Po prostu w większości korpo aplikacji stosowanie tłustych wzorców projektowych i architektur nie ma sensu bo niepotrzebnie komplikuje zwykle proste rozwiązanie i wpływa negatywnie na koszt projektu. A takich rasowych projektów gdzie sprawdziłoby się DDD i mikroserwisy czy serverless jest zwyczajnie mało i trzeba mieć duże szczęście żeby do takiego projektu trafić bo jego sens biznesowy musi uzasadniać wysokie koszty nie tylko wytworzeniaPokaż całość

@montmartre: Aspirujesz do bycia architektem więc rada od architekta z wieloletnim stażem - jako architekt będziesz pomiędzy biznesem i zespołem projektowym i będziesz musiał wybierać pomiędzy idealną architekturą a oczekiwaniami biznesu i tłumaczyć programistom dlaczego akurat dziś trzeba zrobić hacka w kodzie żeby dowieźć ficzer "na wczoraj" zamiast głebokiej refaktoryzacji, która zajmie tydzień i kod będzie clean, ale przez ten czas biznes będzie w plecy 50k $

Tak samo w drugąPokaż całość

@montmartre:

Szczęście w nieszczęściu, że pierwsza rada dość mocno jest pokryta przez moją osobowość socjopatyczną. Jak ogromnie mi to niszczy życie osobiste, tak zauważyłem, że w kwestiach zawodowych mam znaczącą przewagę w wielu dyskusjach.

No to jeszcze musisz popracować nad tym by swoją socjopatyczność ukryć za miłą buźką - w biznesie większość ludzi to mniejsi lub więksi socjopaci ale ukrywający się za ładnym wyglądem i "szczerym" uśmiechem. Wystarczy popatrzeć na największychPokaż całość

@cordianss: Mówię ogólnie o branży i wysokopoziomowej architekturze rozwiązania tak żeby nie zdradzać zbyt wielu szczegółów.

@aczutuse: Odpowiedź jest prosta. Czy jest to część twojej domeny biznesowej to znaczy czy jest czymś unikalnym i stanowi o wartości/przewadze biznesową nad konkurencją, czy jest zwykłym szczegółem technicznym/implementacyjnym? Jeśli to pierwsze to powinno być częścią domeny. Jeśli to drugie to powinno być częścią warstwy infrastruktury.

Przykładowo jeśli twoja firma zajmuje się dostarczaniem rozwiązań do parsowania xml-i, json-ów, csv-ów itd to obiekty wykonujące taką logikę są w rozumieniu DDD dziedziną głównąPokaż całość

@aczutuse:

a mapper, który mapuje obiekt domenowy na dto? W pakiecie web gdzie jest RestController? Czy do adapterów? A może do domeny, bo to trochę logika biznesowa pt. "jak prezentować nasz obiekt"?

to szczegół implementacyjny/util więc poza domeną - po co domena ma wiedzieć cokolwiek o warstwie prezentacji/API?

Ja słyszałem se, że jak ktoś robi pakiet utils to jest złym programistą ech

Nie napisałem że masz robić pakiet utils, tylko żePokaż całość

----TutajSerwajs.java

Czemu serwajs jest w warstwie infrastruktury nie aplikacji? Zwykle serwisy aplikacyjne odpowiedzialne za wykonanie jakiegoś use case'a jak nazwa mówi siedzą w warstwie aplikacji, chyba że to jakiś inny serwis, nie wiem. Zwykle jest tak, że web controller woła serwis aplikacyjny albo handler jak używasz CQRS i ten serwis/handler zajmuje się orkiestracją obiektów domenowych. Czyli pobiera agregat z bazy danych wykonuje logikę, zapisuje stan agregatu za pomocą repozytorium i jak trzebaPokaż całość

@aczutuse: Jeśli w twoim przypadku umieścisz DTO w web, który jest częścią infrastruktury, to w jaki sposób serwis aplikacyjny który nie powinien mieć referencji do komponentów będących częścią warstwy infrastruktury będzie na nich operował? Nie możesz mieć sytuacji w której pakiet web ma referencję do application i jednoczesnie application ma referencję do web.

Jeśli serwis operuje na DTO i jednocześnie jest wywoływany w kontrolerze to DTO muszą siedzieć w pakieciePokaż całość

@aczutuse: Tu już poruszasz inne zagadnienie - struktury pakietów w aplikacji. Są różne szkoły i opinie. Dużo zależy od skali aplikacji. Jak masz relatywnie prostą domenę, to taki podział jaki pokazałeś gdzie obiekty domenowe siedzą w jednym pakiecie ma sens.

W przypadku gdy robisz coś bardziej złożonego jak modularny monolit i masz kilka bounded contextów i subdomen w jednej aplikacji to wtedy podział po subdomenach/kontekstach ma więcej sensu. I wtedy maszPokaż całość

@aczutuse:

no, bo przy takim podziale chyba szyskie klasy publiczne muszom być a można by tak pogrupować by były package scope i tylko serwis public i agregat ewentualnie

tak, przy package by feature można zastosować package scope. Przy package by layer to klasy muszą być publiczne. Można też połączyć jedno i drugie. Ale to wymaga już głębszej analizy, planowania i doświadczenia.

koliego, a czu jak mam se 2 domeny czyli

Pokaż całość

springowe eventy są fajne, można w runtime zrobić se

@aczutuse: No można, wszystko zależy od wymagań. Jeśli logika biznesowa pozwala na gwarancję dostarczenia wiadomości w modelu at-most-once to takie zdarzenia in memory są ok. Jeżeli okazałoby się że wymagane jest at-least-once delivery to trzeba się posiłkować jakimś data store i wzorcem Outbox Pattern, żeby mieć pewność że zdarzenie nie zginęło "po drodze"

czu a to nawet nie wiedzialem se, ze te springowe sa at-most-once hms

@aczutuse: nie znam Springa więc mogę być w błędzie niemniej trzeba zrobić sobie mały eksperyment myślowy. Co się stanie jeśli stan agregatu A zostanie zapisany w reakcji na co zostanie wyemitowany event E i w trakcie obsługi zdarzenia E przez handler EH kontener aplikacji stwierdzi że to najwyższa pora na restart. Czy po restarcie Spring jest w staniePokaż całość

@aczutuse: Infra bo to jest szczegół implementacyjny. Dziś używasz wbudowanych Springowych komponentów, a jutro możesz chcieć użyć dedykowanej zewnętrznej biblioteki, a po jutrze będziesz chciał odpalać job-a poza procesem aplikacji żeby mieć pewność, że jak padnie aplikacja to job będzie sobie dalej działał.

Co do osobnego pakietu to zależy od skali i struktury projektu. Ja preferuję mieć osobne pakiety. Czyli mam pakiet z adapterami do bazy danych, pakiet z adapterami doPokaż całość