Temat: Encje w DDD

Jakub Wojt:
Trochę inaczej na to patrzę.
Obiekt to stan + zachowanie.

nie wymyślajmy nowych bytów: obiekt to koncept mający atrybuty i operacje (ich metody), które mogą między innymi zmieniać wartość atrybutów, nie każdy obiekt jest stanowy, "stan" obiektu to pojęcie zarezerwowane dla modelu maszyny stanowej (stan/status obiekty jest przechowywany jako jeden z atrybutów), są obiekty bezstanowe nie licząc faktu że istnieją lub nie ale to już nie stany...

http://download.oracle.com/javase/tutorial/java/concep...

Repozytorium przechowuje stany obiektów.

Repozytorium przechowuje obiekty...
http://martinfowler.com/eaaCatalog/repository.html

Fabryka 'owija' te stany (przynajmniej identyfikator i typ obiektu) w jakieś 'zachowanie' w wyniku czego powstaje obiekt i ten zostaje zwrócony do systemu; przynajmniej tak jej działanie rozumiem w kontekście tworzenia obiektów domeny / wzorca DDD.

Fabryka to konstrukcja, której rolą jest tworzenie nowych złożonych obiektów/agregatów

http://en.wikipedia.org/wiki/Factory_method_pattern

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

Kontener to coś co przechowuje obiekty. :)

kontener to obiekt, którego rolą jest zarządzania swoja zawartością: obiektami, agregat.

http://best-practice-software-engineering.ifs.tuwien.a...

Hm.. 'kontener' wycofuję, nie powinien się znaleźć na liście a przynajmniej nie w tym kontekście ;)

Jeżeli analityk i projektant ma się dogadywać z programistami to lepiej niech nie wymyśla własnych standardów tylko stosuje te powszechnie uznane.. ;)
sugeruje leksturę:

http://en.wikipedia.org/wiki/Design_Patterns

Temat: Encje w DDD

Wojciech Soczyński:

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

Tak też Evans bodajże stwierdził, że DDD to nic nowego, tylko zebrane i usystematyzowane pewne praktyki. W każdym razie jest to jakaś metodyka konkretna skoro ma swoją nazwę. Jaki więc termin proponujesz jako synonim słowa Encja, dla Encji w rozumieniu DDD ?

moim zdaniem słowo "entity" ma co najmniej dwa tłumaczenia i użycia w języku polskim:
- byt (coś konkretnego co istnieje w świecie rzeczywistym lub pojęcie)
- encja w modelu relacyjnym

dlatego poza modelem relacyjnym preferuję używania słowa "byt" a nie kalki z angielskiego jaką jest "encja". I tak od razu wyjaśnia się, że "byty" świata rzeczywistego są reprezentowane przez obiekty modelu dziedziny czy też obiekty w DDD reprezentują "wiernie" (modelują) byty świata rzeczywistego (a nie encje).

Temat: Encje w DDD

Jakub Wojt:

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.

DDD definiuje je trochę inaczej:
Entity: An object that is not defined by its attributes, but rather by a thread of continuity and its identity.

dalej
... domain objects should be defined purely to implement the business behaviour of the corresponding domain concept, rather than be defined by the requirements of a more specific technology framework

Do implementacji funkc. biznesowej używane są obiekty domeny.
Jeśli w entity jest implementowany 'biznes' to jest to pomieszanie odpowiedzialności.

Ok, czyli rozumiem, że jako Encję rozumiałeś Encję w znaczeniu "bazodanowym" natomiast ja miałem w zamyśle Encje jako przytoczony przez Jarka "byt" ?

Temat: Encje w DDD

Nie rozumiem, czemu mamy nie używać słowa encja? To tak samo można przecież zignorować obiekty wartości, a przecież Ich dokładne rozróżnienie jest poniekąd kluczem do zaprojektowania zgrabnej - i co ważniejsze mniej skomplikowanej - dziedziny.

Co do pytania Wojtka.

Wojciech Soczyński:
Co będzie lepszą praktyką ?

1. dostarczanie obiektów kolaborujących w konstruktorze
2. dostarczanie obiektów kolaborujących jako argument konkretnej metody
3. użycie wzorca strategi, gdzie dla danej metody encji, dostarczamy jakiś "black box", który posiada już wszystkie zależności

Chyba nie ma złotego środka, trzeba po prostu wybrać rozwiązanie najlepiej wpisujące się w warunki dziedziny. Ja to widzę tak:

1. Konstruktor.
plusy: Jest to od strony kodu najładniejszym rozwiązaniem, bo jasno i przejrzyście pokazuje zależności. W przeciwieństwie do wstrzykiwania przez settery, są to zależności twarde (programista nie musi sprawdzać, czy wymagany obiekt zewnętrzny na pewno istnieje).
minusy: Tworzenie obiektu staje się uciążliwe. Owszem, można załatwić to poprzez stworzenie fabryki obiektu, jednak jest to rozwiązanie często mało kompatybilne z ORMami (trzeba tworzyć dodatkowy kod specjalnie pod nie, a to nie jest szczególnie DRY).

2. Double dispatch.
plusy: Proste i szybkie + zależności twarde.
minusy: Często wymusza zmianę API/sygnatur metod oraz ich wydłużenie. Osobiście tego nie lubię.
Jako przykład podam logowanie zdarzeń z Loggerem zapodawanym w ten sposób. Chyba nigdy nie ma tak, że ilość miejsc z których chcielibyśmy zapisywać logi - w całym systemie - się zmniejsza. Raczej Ich przybywa... a razem z tym ten jeden dodatkowy argument w metodzie.

W dodatku lekko przyciemnia obraz zależności, bo na dobrą sprawę ta sama zależność może być zdefiniowana w kilku miejscach (na pewno jest na to jakaś nazwa).

3. Strategia.
Nie dotyczy.
Wzorzec strategii nie polega na dostarczeniu zależności, a implementacje strategii mają ten sam problem o którym jest ten cały temat.
To co nazwałeś "Black boxem" bardziej przyrównałbym do jakiegoś kontekstu niż strategii.

Najczęściej używam 1 z kilkoma "ale".
1. Minimalizuje ilość miejsc w których tworze obiekty. W uproszczeniu: obiekt giełdy tworzy transakcje na podstawie parametrów (co, ile, za ile) z ofert kupna/sprzedaży (które notabene też trzyma w sobie i nimi zarządza), a nie ja tworze tą transakcje i przekazuje do giełdy + usuwanie/modyfikacja ofert.
Generalnie chodzi o korzystanie z "aggregate roots".
2. Minimalizuje ilość zależności poprzez wykorzystanie "domain events" np. gdy tworzona jest transakcja, nie potrzebuje obiektu Mailera do wysłania maila, wystarczy mi to, że powiadomię o tym system, a mailem zajmie się obiekt nasłuchujący.
3. Wszystkie serwisy, fabryki i repozytoria trzymam w kontenerze IoC.

Temat: Encje w DDD

Obiekt to stan + zachowanie.

nie wymyślajmy nowych bytów: obiekt to koncept mający atrybuty

... których wartości określają stan

i operacje (ich metody),

... zachowanie

które mogą między innymi zmieniać wartość atrybutów, nie każdy obiekt jest > stanowy,
"stan" obiektu to pojęcie zarezerwowane dla modelu maszyny
stanowej (stan/status obiekty jest przechowywany jako jeden z
atrybutów),

'stan' to bardzo pojemne pojecie

są obiekty bezstanowe nie licząc faktu że istnieją lub nie ale to już nie stany...

http://download.oracle.com/javase/tutorial/java/concep...

Real-world objects share two characteristics: They all have state and behavior. ?

Repozytorium przechowuje stany obiektów.

Repozytorium przechowuje obiekty...
http://martinfowler.com/eaaCatalog/repository.html

hm.. rzeczywiście... ale przy takiej definicji factory jest tylko szczególnym przypadkiem repository tzn: factory nie pobiera danych z 'db'

według mnie, w kontekście tego ze zachowanie obiektu zależy od klasy a nie stanu, to trochę bez sensu, ale to temat a inna dyskusję...

Fabryka 'owija' te stany (przynajmniej identyfikator i typ obiektu) w jakieś 'zachowanie' w wyniku czego powstaje obiekt i ten zostaje zwrócony do systemu; przynajmniej tak jej działanie rozumiem w kontekście tworzenia obiektów domeny / wzorca DDD.

Fabryka to konstrukcja, której rolą jest tworzenie nowych złożonych obiektów/agregatów

hm ... w tym artykule się nie mówi się, na podstawie czego ma powstać dany obiekt.
tzn może powstać obiekt 'z niczego' a możne na podstawie danych z db (stanu)

Jeżeli analityk i projektant ma się dogadywać z programistami to lepiej niech nie wymyśla własnych standardów tylko stosuje te powszechnie uznane.. ;)
sugeruje leksturę:
http://en.wikipedia.org/wiki/Design_Patterns

hehe ok; pytanie za 100 pkt: czym container się rożni od repository (poza nazwa oczywiście)? :>
czas start...

Temat: Encje w DDD

nie wymyślajmy nowych bytów: obiekt to koncept mający atrybuty

... których wartości określają stan

ja jako "obiekt" mam atrybuty, np. wiek, kolor skóry, a to nie jest mój "stan", ten co najwyżej czasami jest wskazujący na spożycie....

i operacje (ich metody),

... zachowanie

potrafię wykonać polecenia: idź, zatrzymaj się, policz do dwóch, ale to umiejętności, zachowanie ma nieco inne znaczenie (zbliżone ale inne).

http://download.oracle.com/javase/tutorial/java/concep...

Real-world objects share two characteristics: They all have state and behavior. ?

nie zapominajmy o pewnych różnicach w semantyce słów w różnych językach, "state" to także stan Waszyngton w USA....

Repozytorium przechowuje obiekty...
http://martinfowler.com/eaaCatalog/repository.html

hm.. rzeczywiście... ale przy takiej definicji factory jest tylko szczególnym przypadkiem repository tzn: factory nie pobiera danych z 'db'

ja jednak widzę istotną różnice pomiędzy wyprodukowaniem roweru a pobraniem gotowego z magazynu...

Fabryka to konstrukcja, której rolą jest tworzenie nowych złożonych obiektów/agregatów

hm ... w tym artykule się nie mówi się, na podstawie czego ma powstać dany obiekt.
tzn może powstać obiekt 'z niczego' a możne na podstawie danych z db (stanu)

bo powstaje "z niczego" :), powstaje "pusty" i ewentualnie otrzymuje pierwotne atrybuty...

hehe ok; pytanie za 100 pkt: czym container się rożni od repository (poza nazwa oczywiście)? :>
czas start...

Kontener to np. teczka sprawy z dokumentami, repozytorium to archiwum tych dokumentów (całych teczek) gdzie teczkę oddajemy na przechowanie.... celowo podaje ten przykład, bo wiele systemów zarządzania dokumentami nie udało sie z powodu braku zrozumienia tego wzorca:

po rak kolejny mam wrażenie, że wielu ludzi zajmujących się implementacją nie potrafi już patrzeć na to abstrakcyjnie...

Temat: Encje w DDD

Jarek Żeliński:

Kontener to np. teczka sprawy z dokumentami, repozytorium to archiwum tych dokumentów (całych teczek) gdzie teczkę oddajemy na przechowanie.... celowo podaje ten przykład, bo wiele systemów zarządzania dokumentami nie udało sie z powodu braku zrozumienia tego wzorca:

po rak kolejny mam wrażenie, że wielu ludzi zajmujących się implementacją nie potrafi już patrzeć na to abstrakcyjnie...

Czyli reasumując - repozytorium jest częścią warstwy infrastruktury a kontener domeny ?

Temat: Encje w DDD

Wojciech Soczyński:
Czyli reasumując - repozytorium jest częścią warstwy infrastruktury a kontener domeny ?

Patrząc przez pryzmat projektowania i DDD raczej nie :)

- kontener odpowiada za zarządzanie pewną pulą obiektów (kolekcją), nie muszę się grzebać sam w fakturach, odwołuję się do ich "teczki", każda faktura z osobna wie czego dotyczy, ale jak mi potrzebna jakaś konkretna faktura lub ich część (np. tylko faktury z lipca lub tylko faktury za rowery) to proszę o nie Kontener a nie grzebię w nich sam; kontener ukrywa przede mną złożoność tych dokumentów i ich ilość a także potencjalna zmienność (np. z powodu zmian przepisów) czyli nawet jak zmienią się przepisy, treść faktur, kolumny itp., pytanie do Kontenera: "poproszę o faktury o wartości większej od 100zł dla kowalskiego" zawsze da w rezultacie odpowiedź, nikt w firmie (reszta systemu) nie musi mieć pojęcia, że faktury mają nowe wzory, pola itp.

- repozytorium: doskonały przykład to komponent z interfejsem (tu jako cloud) Amazon A3, Kontener nie będzie sam się grzebał w żadnej bazie SQL tylko będzie trzymał te faktury w Repozytorium, ono ukrywa fizyczną implementacje bazy przez wszystkimi.
http://aws.amazon.com/s3/

parząc z perspektywy DDD mam tu klasyczne "odwzorowanie bytów świata rzeczywistego w modelu dziedziny", i kontener (agregat) i repozytorium, oba są elementami domeny i mamy takie właśnie wzorce zalecane dla DDD. W DDD nie mam mowy o implementacji modelu, tym się zajmuje reszta warstw/komponentów. DDD jako "wspólny język" opisuje (modeluje) tylko świat rzeczywisty. Resztę załatwia pozostała część (framework) np. wzorca MVC.

W prostych systemach stosuje się często łączenie roli Agregatu i Repozytorium w jednym bycie jakim jest Agregat, jednak dobry projekt pozwala na wyniesienie operacji realizujących utrwalanie (powinny być to operacje prywatne tego Agregatu) z Agregatu do odrębnego Repozytorium, które może być tylko interfejsem do zewnętrznej usługi (np. ten Amazon).

w sieci i w literaturze można się spotkać z tymi wzorcami (Model, View, Controller, Repository) by wskazać na tę właśnie strukturę, "wyjmującą" operacje utrwalania z Modelu Dziedziny co moim zdaniem jest bardzo użyteczną techniką projektowania. Pozwala analitykowi i projektantowi logiki biznesowej w 100% oddzielić się od projektowania implementacji utrwalania a developerowi oddzielić od projektowania tej logiki... tu przykłądy:

http://blog.wekeroad.com/mvc-storefront/asp-net-mvc-mv...

http://www.pzielinski.com/?p=281

jak widać podejścia są nieco różne ale wzorce te są stosowane, ja jestem zwolennikiem oddzielenia Agregatu od Repozytorium, gdyż Agregat odpowiada za zarządzanie konkretną kolekcją (może np. korzystać z Fabryki dokumentów, może mieć swoja dedykowaną Fabrykę) a Repozytorium oferuje usługę dla wszystkich agregatów.Jarek Żeliński edytował(a) ten post dnia 01.07.11 o godzinie 10:14

Temat: Encje w DDD

Jarek Żeliński:
- kontener odpowiada za zarządzanie pewną pulą obiektów (kolekcją), nie muszę się grzebać sam w fakturach, odwołuję się do ich "teczki", każda faktura z osobna wie czego dotyczy, ale jak mi potrzebna jakaś konkretna faktura lub ich część (np. tylko faktury z lipca lub tylko faktury za rowery) to proszę o nie Kontener a nie grzebię w nich sam; kontener ukrywa przede mną złożoność tych dokumentów i ich ilość a także potencjalna zmienność (np. z powodu zmian przepisów) czyli nawet jak zmienią się przepisy, treść faktur, kolumny itp., pytanie do Kontenera: "poproszę o faktury o wartości większej od 100zł dla kowalskiego" zawsze da w rezultacie odpowiedź, nikt w firmie (reszta systemu) nie musi mieć pojęcia, że faktury mają nowe wzory, pola itp.

Tutaj pytanie:
w twoim przykładzie związanym z fakturami, jakikolwiek obiekt poza kontenerem będzie miał możliwość "obcowania" obiektem klasy faktura, czy też wszystko będzie się odbywało za pośrednictwem kontenera ?

Pytam ze względu np na przypadek taki, że chciałbym się dowiedzieć o wysokość jednej z faktur, czy powinienem zrobić to tak:

kontenerFaktur.wysokoscFaktury(numerFaktury);

czy może tak

kontenerFaktur.znajdz(numerFaktury).wysokosc();

a może oba sposoby są równorzędne ?

Oczywiście pierwszy przypadek jest bardziej "abstrakcyjny" - zewnętrzne obiekty nie muszą nic wiedzieć o klasie faktury, ale z drugiej strony drugi to "mniej klepania" dla programisty ( ;p ).

Temat: Encje w DDD

optuję za pierwszym przypadkiem :), idąc do księgowej proszę:
- pani księgowo, wyszukaj fakturę 12/2011 i podaj mi jej wartość
- pani księgowo, jaka była wartość faktury 12/2011

:), im bardziej to uprościsz tym bardziej oddalasz się od "wspólnego języka" DDD... gdyby prezes tej firmy znał UML którą wersje by wybrał???

poza tym "znajdź" to prywatna metoda księgowej :), po drugie jako projektant nie kupuje argumentu "mniej klepania dla programisty" :) bo rolą programisty jest to klepanie wykonać i wycenić :) a nie upraszać ;)Jarek Żeliński edytował(a) ten post dnia 01.07.11 o godzinie 11:01

Temat: Encje w DDD

Jarek Żeliński:
to jest moim zdaniem źródło wielu problemów z jakością oprogramowania, osobiście uważam, że należy używać techniki najlepiej pasującej do problemu a nie najwygodniejszej dla zespołu, bo jakie będą skutki tego samego twierdzenia gdy kowali wpuścimy do problemu z zepsutym zegarkiem?

W ogólności zgoda, natomiast tutaj zastanawialiśmy się, czy do zepsutego zegarka wpuścić zegarmistrza z 2-letnim (technika nr 1), czy z 10-letnim stażem (technika nr 2). O obu wiemy, że dobrze rozwiążą problem.

Temat: Encje w DDD

nie mniej jednak ale wieloletni staż pracy kowala nie zmienia faktu, że zegarka młotkiem raczej nie naprawimy - co najwyżej zutylizowawszy :)

wracając do programistów: każdy kolejny projekt pokazuje mi, że programiści "myślą implementacją" 9i słusznie, bo od tego są) ale dawanie im fazy "analizy i projektowania" w 100% bazującej na abstrakcjach, prawie zawsze kończy się porażką projektu, zaś rosnący staż pracy "eksperta" jako programisty tylko powiększa prawdopodobieństwo tej porażki...Jarek Żeliński edytował(a) ten post dnia 01.07.11 o godzinie 12:49

Temat: Encje w DDD

Jarek Żeliński:
nie mniej jednak ale wieloletni staż pracy kowala nie zmienia faktu, że zegarka młotkiem raczej nie naprawimy - co najwyżej zutylizowawszy :)

Pas ;)

wracając do programistów: każdy kolejny projekt pokazuje mi, że programiści "myślą implementacją" (i słusznie, bo od tego są) ale dawanie im fazy "analizy i projektowania" w 100%
bazującej na abstrakcjach, prawie zawsze kończy się porażką projektu, zaś rosnący staż pracy "eksperta" jako programisty tylko powiększa prawdopodobieństwo tej porażki...

Nie odkryję Ameryki pisząc, że problem jest ogólniejszy i sprowadza się do umniejszania znaczenia szeroko pojętego planowania (tu: projektowania) na rzecz budowania (tu: implementacji). I wcale nie jest charakterystyczny dla IT.

Pytanie czy użyteczna u programistów byłaby zdolność odcięcia się od szczegółów implementacyjnych (i czy to w ogóle możliwe).

Temat: Encje w DDD

Jeszcze jedna uwaga.

Repozytorium (mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects) zdecydowanie spełnia kryteria tak pojętego kontenera (an object created to hold other objects that are accessed, placed, and maintained with the class methods of the container).

Z traktowaniem księgowego jako kontener byłbym już mocno ostrożny (czy ma on operacje dodajFakturę i usuńFakturę?).Andrzej Chodor edytował(a) ten post dnia 01.07.11 o godzinie 18:09

Temat: Encje w DDD

Andrzej Chodor:
Nie odkryję Ameryki pisząc, że problem jest ogólniejszy i sprowadza się do umniejszania znaczenia szeroko pojętego planowania (tu: projektowania) na rzecz budowania (tu: implementacji). I wcale nie jest charakterystyczny dla IT.

a tu zgoda w 100% :)

Pytanie czy użyteczna u programistów byłaby zdolność odcięcia się od szczegółów implementacyjnych (i czy to w ogóle możliwe).

jeśli dobrze rozumiem to: moim zdaniem nie i dlatego nie powinni brać udziały w pierwszych etapach projektów prowadzonych metodą top-down, a tak generalnie wyglądają projekty oprogramowania .....

Temat: Encje w DDD

Andrzej Chodor:
Jeszcze jedna uwaga.

Repozytorium (mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects) zdecydowanie spełnia kryteria tak pojętego kontenera (an object created to hold other objects that are accessed, placed, and maintained with the class methods of the container).

jak wspomniałem zależnie od konkretnej sytuacji to jest stopnia komplikacji zarządzanych obiektów w kontenerze, w wielu projektach ma sens łączenie agregatu (kontenera) z repozytorium, ... to już szczegóły... danego przypadku, generalnie miałem na myśli to, ze Repozytorium umieszcza się pomiędzy bazą fizyczna na modelem dziedziny.

Z traktowaniem księgowego jako kontener byłbym już mocno ostrożny (czy ma on operacje dodajFakturę i usuńFakturę?).

to zależy czy "księgowy" jest fakturzystą czy nie, po drugie FabrykaFaktur może być odrębnym od kontenera obiektem (i tak często to robię), mamy trzy role:
1. twórca faktur (np. fabryka)
2. zarządca faktur wystawionych (Kontener)
3. pudło na faktury (Repozytorium)

dzięki temu:
1. przestaje mieć znaczenie to czy faktura powstała w naszym czy cudzym systemie
2. jest jedno miejsce (Kontener) mające całą wiedzę o wystawionych już fakturach
3. można w dowolnym momencie wymieć implementację utrwalania

Temat: Encje w DDD

hehe ok; pytanie za 100 pkt: czym container się rożni od repository (poza nazwa oczywiście)? :>
czas start...

Kontener to np. teczka sprawy z dokumentami, repozytorium to archiwum tych dokumentów (całych teczek) gdzie teczkę oddajemy na przechowanie....

Teczka też 'przechowuje', a dokumenty archiwalne to też dokumenty. Czy 'teczka' która zawiera dokumenty (container) archiwalne to repository ?...

Jedyna różnica jaka przyszła mi do głowy jest taka, że kontener ma (a przynajmniej powinien) enumerator. Repository enumeratora mieć nie musi (...technologia nie pozwala) .Jakub Wojt edytował(a) ten post dnia 02.07.11 o godzinie 00:05

Temat: Encje w DDD

Do implementacji funkc. biznesowej używane są obiekty domeny.
Jeśli w entity jest implementowany 'biznes' to jest to pomieszanie odpowiedzialności.

Ok, czyli rozumiem, że jako Encję rozumiałeś Encję w znaczeniu "bazodanowym" natomiast ja miałem w zamyśle Encje jako przytoczony przez Jarka "byt" ?

W DDD to się nazywa 'obiekt domeny'.

... a przynajmniej tak mi się wydaje, bo tutaj: http://en.wikipedia.org/wiki/Domain-driven_design nic się o tym nie mówi.

Temat: Encje w DDD

Jakub Wojt:

Do implementacji funkc. biznesowej używane są obiekty domeny.
Jeśli w entity jest implementowany 'biznes' to jest to pomieszanie odpowiedzialności.

Ok, czyli rozumiem, że jako Encję rozumiałeś Encję w znaczeniu "bazodanowym" natomiast ja miałem w zamyśle Encje jako przytoczony przez Jarka "byt" ?

W DDD to się nazywa 'obiekt domeny'.

... a przynajmniej tak mi się wydaje, bo tutaj: http://en.wikipedia.org/wiki/Domain-driven_design nic się o tym nie mówi.

Cóż, myślę, że fundamentalnym problemem w naszej dyskusji na temat DDD, jest jak na razie kwestia nazewnictwa i jakoś przydało by się ją ujednolicić, żeby uniknąć niejasności...

Temat: Encje w DDD

Jarek Żeliński:
to zależy czy "księgowy" jest fakturzystą czy nie, po drugie FabrykaFaktur może być odrębnym od kontenera obiektem (i tak często to robię), mamy trzy role:
1. twórca faktur (np. fabryka)
2. zarządca faktur wystawionych (Kontener)
3. pudło na faktury (Repozytorium)

Jarku, tutaj wszystko się zgadza (dzięki za tak łopatologiczne wyjaśnienie - to bardzo przydatne!) za wyjątkiem jednego słowa: kontener.

Cały czas upieram się, że kontener to nie obiekt, który zarządza, ale raczej obiekt, który umożliwia zarządzanie innymi obiektami with the class methods of the container. W artykule, który sam podlinkowałeś, nazywany jest także kolekcją. Podobne znaczenie przypisuje kontenerowi poczciwy, PWN-owski słownik:
kontener «pojemnik o znormalizowanych wymiarach, używany do przechowywania i transportu towarów»

Owe metody umożliwiające zarządzanie są świetnie zdefiniowane na pudle: umieść w pudle, wyjmij z pudła. Dobrze określony jest nawet iterator - palec przeglądającego umieszczony za przeglądaną właśnie fakturą.

Wydaje mi się, że zarządcy (agregaty) korzystają raczej z kontenerów (pudeł, szaf, segregatorów, regałów na segregatory) niż sami nimi są. Repozytoria natomiast to takie szczególne kontenery lub przystawki do innych obiektów (np. magazynów, archiwów, złożonych systemów informatycznych) umożliwiające posługiwanie się nimi w sposób typowy dla kontenerów. Odkładając na moment poprawność, takim repozytorium może być pani Marzenka zarządzająca naszym kalendarzem:
- Pani Marzenko, jestem umówiony z Kowalskim na jutro na 12 (operacja add kontenera),
- Pani Marzenko, mam dosyć Kowalskiego, nie spotkam się z nim dzisiaj (operacja remove kontenera),
- Pani Marzenko, co mam zaplanowane na dzisiaj? (iterator).
Nawet po podmianie kalendarza pani Marzenki na nowy, elektroniczny, gdzieś w chmurze, pani Marzenka i te trzy operacje na niej pozostaną te same.Andrzej Chodor edytował(a) ten post dnia 02.07.11 o godzinie 11:59