Temat: Encje w DDD

Link do wypowiedzi

Temat: Encje w DDD

Link do wypowiedzi

Temat: Encje w DDD

Link do wypowiedzi

Temat: Encje w DDD

Wojciech Soczyński:
Z drugiej strony, wszelakie biblioteki typu ORM, dzięki którym utrwalamy
encje wymagają np. bezargumentowego konstruktora. Jak wobec tego rozwiązać > ten dylemat ? Co będzie lepszą praktyką ?

Wojciech Soczyński:
Kolejna kwestia która mnie zastanawia, a którą już podnosiłem tu na forum jest kwestia powiązań między obiektami. Jarek Żeliński sugeruje by posługiwać się atrybutami bezpośrednio, czyli załóżmy mamy Zawodnika i on ma atrybut (string) drużyna i na tej podstawie sobie może coś zrobić np. znaleźć tą drużynę w jakimś repozytorium etc(przynajmniej ja to tak zrozumiałem)....

Link do wypowiedzi

Temat: Encje w DDD

Link do wypowiedzi

Temat: Encje w DDD

Link do wypowiedzi

Temat: Encje w DDD

Psikus Psajkus:
Siema,
zastanawiam się czy we dopuszczalne jest uzycie repozytorium w encji, (chodzi mi o metode setProfil)

[php]
class UserEntity
{
//jakies atrybuty

//jakies metody

/** @var ProfilEntity */
private $_oProfil;

public function addProfil(ProfilEntity $oProfilEntity)
{
$this->_oProfil = $oProfilEntity;
}

public functin getProfil()
{
if(!isset($this->_oProfil)
{
return $this->setProfil();
}
else
{
return $this->_oProfil;
}
}

private function setProfil()
{
$oProfilRepository = new ProfilRepository;

return $oProfilRepository->find();
}

}

class ProfilEntity
{
//jakies atrryburty i metody
}

[/php]

Czy powinienem odwoływac się do repozytorium z poziomu encji czy raczej przeslać obiekt (wykorzystujac metode addProfil). Jak wy robicie?

Link do wypowiedzi

Temat: Encje w DDD

Witajcie,

zastanawia mnie [...] jest do klas usługowych, a encje są kontenerami na dane.

Logicznym więc jest, że w tym wypadku to Encje (i również Aggregate Roots) będą obiektami w których najwięcej się "dzieje". Problem pojawia się w momencie, gdy encja potrzebuje jakieś obiekty kolaborujące by sprawnie działać.

Jakie jest Wasze zdanie ?

Link do wypowiedzi

Temat: Encje w DDD

Odpowiedź (z punktu widzenia wciąż raczkującego w DDD, jestem strasznie ciekaw opinii wyjadaczy:) jest prosta: używaj takiej techniki, która jest dla Ciebie/Twojego zespołu najwygodniejsza.

Link do wypowiedzi

Temat: Encje w DDD

Też skłaniam się ku rozwiązaniu numer 2. Natomiast co do przyziemności, to problem jest taki, że w internecie jest dużo materiałów teoretycznych, natomiast samego kodu albo jest mało, albo nie jest on w żaden sposób konkretnie opisany. Dlatego też dla programisty, który chciałby wykorzystać choćby w ograniczonym stopniu metodykę DDD w swoim kodzie (małe projekty) oznacza to błądzenie we mgle.

Kolejna kwestia która mnie zastanawia, a którą już podnosiłem tu na forum jest kwestia powiązań między obiektami. Jarek Żeliński sugeruje by posługiwać się atrybutami bezpośrednio, czyli załóżmy mamy Zawodnika i on ma atrybut (string) drużyna i na tej podstawie sobie może coś zrobić np. znaleźć tą drużynę w jakimś repozytorium etc(przynajmniej ja to tak zrozumiałem), natomiast w praktyce ciężko to widzę, bo w końcu co będzie jak nazwa drużyny się zmieni ? Chociaż patrząc z punktu widzenia świata rzeczywistego to wszelkie tego typu zmiany pociągają za sobą tak naprawdę stworzenie nowej encji z nowym atrybutem (vel np. zmiana nazwy firmy w urzędzie).\

Link do wypowiedzi

Temat: Encje w DDD

Link do wypowiedzi

Temat: Encje w DDD

Obiekty domeny powinny mieć możliwość pobrania (na podstawie swojego ID) obiektów kolaborujących z fabryki / kontenera.

Link do wypowiedzi

Temat: Encje w DDD

Jakub Wojt:

Witajcie,

zastanawia mnie [...] jest do klas usługowych, a encje są kontenerami na dane.

i tak właśnie powinno być ;)

Logicznym więc jest, że w tym wypadku to Encje (i również Aggregate Roots) będą obiektami w których najwięcej się "dzieje". Problem pojawia się w momencie, gdy encja potrzebuje jakieś obiekty kolaborujące by sprawnie działać.

Encja nie jest od tego, żeby realizować funkcjonalność biznesową.

Jakie jest Wasze zdanie ?

Obiekty domeny powinny mieć możliwość pobrania (na podstawie swojego ID) obiektów kolaborujących z fabryki / kontenera.

Link do wypowiedzi

Temat: Encje w DDD

Jarek Żeliński:
moim zdaniem problem leży gdzie indziej, należy odróżniać projektowanie od implementacji, DDD to projektowanie a nie programowanie...

Link do wypowiedzi

Temat: Encje w DDD

Jarek Żeliński:
Mam propozycję: uporządkujmy jakość rozmowy nie używając słowa encja w rozmowie o DDD bo tu mamy obiekty i klasy a nie encje...

Link do wypowiedzi

Temat: Encje w DDD

Wojciech Soczyński:

Jarek Żeliński:
moim zdaniem problem leży gdzie indziej, należy odróżniać projektowanie od implementacji, DDD to projektowanie a nie programowanie...

Z dostępnych materiałów o DDD, z którymi się zapoznałem wynika, że projektowanie jest blisko powiązane z implementacją np "ubiquitous language" etc. Zresztą po co mi projekt, jeżeli nie będę mógł go przełożyć na kod ? Gdy zaprojektuje jakiś diagram klas to logiczne jest, że potem zaimplementuje te klasy w kodzie, jeżeli tak nie jest to jaki ma to sens ?

Link do wypowiedzi

Temat: Encje w DDD

Wojciech Soczyński:

Jarek Żeliński:
Mam propozycję: uporządkujmy jakość rozmowy nie używając słowa encja w rozmowie o DDD bo tu mamy obiekty i klasy a nie encje...

W moich wypowiedziach rozumiem Encję w kontekście DDD jako klasę w kodzie odpowiadającą Encji w modelu domeny, że temat dotyczy implementacji to uważam, że słowo to jest jak najbardziej na miejscu.

Link do wypowiedzi

Temat: Encje w DDD

Jarek Żeliński:

Wojciech Soczyński:

Jarek Żeliński:
Mam propozycję: uporządkujmy jakość rozmowy nie używając słowa encja w rozmowie o DDD bo tu mamy obiekty i klasy a nie encje...

W moich wypowiedziach rozumiem Encję w kontekście DDD jako klasę w kodzie odpowiadającą Encji w modelu domeny, że temat dotyczy implementacji to uważam, że słowo to jest jak najbardziej na miejscu.

uważam, że skoro słowo encja ma "konkretne znacznie" w modelu relacyjnym i na modelach ERD, to warto unikać innych jego znaczeń bo to prowadzi do nieporozumień, jeżeli umówimy się, że nie dotykamy implementacji utrwalania obiektów to znaczy, że pozostajemy na poziomie obiektowej abstrakcji jaką są obiektowe modele DDD, chyba, ze jawnie powiemy, ze mowa o wzorcu implementacyjnym. Model obiektowy to tylko obiekty, ich klasy i związki logiczne ... DDD nie ma tu moim zdaniem nic do rzeczy, DDD to raczej styl projektowania a nie nowy paradygmat...

spotykam słowo encja w tekstach o obiektowych metodach ale "zwalam" to własnie na rozciąganie tego znaczenia... (powiedział bym przeciążanie :)))

Link do wypowiedzi

Temat: Encje w DDD

Obiekty domeny powinny mieć możliwość pobrania (na podstawie swojego ID) obiektów kolaborujących z fabryki / kontenera.

zwracam uwagę, że fabryka tworzy obiekty, repozytorium je przechowuje,

a czym tu jest "kontener" bo chyba nie "kreatorem"? fabryka jest kreatorem, kontener raczej nie....

Link do wypowiedzi

Temat: Encje w DDD

Jakie jest Wasze zdanie ?

Obiekty domeny powinny mieć możliwość pobrania (na podstawie swojego ID) obiektów kolaborujących z fabryki / kontenera.

Nie ma czegoś takiego jak "powinno być" jest wiele sposobów na rozwiązanie danego problemu. W przypadku DDD "encje" realizują funkcjonalność biznesową i na to się kładzie nacisk.

Link do wypowiedzi