Temat: Model dziedziny a operacje

Podczas jednego z moich projektów pojawił się dylemat w zespole: załóżmy, że np. fakturę "rozebrałem" na drobne klejąc ja jako kompozycję jej wystawcy, kontrahenta, pozycji zafakturowanych, stosownych dat itp. i teraz pytanie: operacja wystaw fakturę powinna być w klasie "zbierającej to do kupy" czy jednak powinna powstać klasa WystawiaczFaktur (a może ZarządcaFaktur bo ktoś musi robić raporty), która ma między innymi operacje nowa faktura?

Temat: Model dziedziny a operacje

`Piotr Sowa edytował(a) ten post dnia 12.02.12 o godzinie 15:53

Temat: Model dziedziny a operacje

Jeżeli dobrze rozumiem to wg. Wystawienie faktury jest właściwie operacją modyfikującą istniejącą fakturę, więc jest zmianą wartości pola czyWystawiona na tak, a następnie fakturka powinna być utrwalona w bazie.Łukasz Ważny edytował(a) ten post dnia 01.12.09 o godzinie 14:11

Temat: Model dziedziny a operacje

Generalnie obiekt biznesowy,czyli nasza faktura rozebrana na drobne powinien byc obslugiwany przez jakas osobna klase, ktora wykonuje operacje na tym obiekcie.

Wiadomo, ze obiekt biznesowy powinien sam moc obliczyc np. kwote calkowita faktury, ale sam w sobie nie powinien soba zarzadzac. Traktowac go nalezy jako dane w pewnej formie.

Klasa zarzadzajaca moze robic cokolwiek z obiektem biznesowym. Transformowac go do dowolnej postaci, robic raporty z listy obiektow itp. Nawet z pozoru proste zadanie jak zatwierdzenie faktury moze byc calkiem skomplikowanym w praktyce(np. chec zapisac dodatkowa kopie read-only calej faktury, zwalidowac fakture i wypluc ewentualne bledy itd.).

Pozniej, jezeli klient zechce raportow to mozna po prostu do takeigo zarzadzcy faktur dopisac kod zwaracajacy interesujace nas dane.

Oczywiscie jest to jedno z rozwiazan, ktorych jest na pewno wiecej ;)

pozdrawiam

Temat: Model dziedziny a operacje

Piotr Sowa:

Jarek Żeliński:
Podczas jednego z moich projektów pojawił się dylemat w zespole: załóżmy, że np. fakturę "rozebrałem" na drobne klejąc ja jako kompozycję jej wystawcy, kontrahenta, pozycji zafakturowanych, stosownych dat itp. i teraz pytanie: operacja wystaw fakturę powinna być w klasie "zbierającej to do kupy" czy jednak powinna powstać klasa WystawiaczFaktur (a może ZarządcaFaktur bo ktoś musi robić raporty), która ma między innymi operacje nowa faktura?

Uważam, że powinna być klasa Dokument, oraz klasa ZatwierdzaczDokumentu, Sam dokument powinien być obiektem odwzorowanym w OR/M, którego dodanie było by domyślne w stanie bufor, zatwierdzacz powinien robić wszystkie operacje i przestawiać stan na zatwierdzony, oczywiście wydruk też może robić.
Jeśli projekt jest rozbudowany może powstać obiekt DefinicjaDokumentu, wtedy mając 3 klasy można zamodelować ewidencje handlowe, magazynowe, kaucji i w ogóle małe fakturowanie czy handel ;P.

Pozwole sobie na pewną polemikę :)
Gdzie tu obiektowość? Czym jest ewidencja i ewidencja czego? Jeśli ewidencja towarów to jest to kolekcja obiektów będących produktami, ewidencja sprzedaży to kolekcja np. faktur itp...

Temat: Model dziedziny a operacje

Łukasz Ważny:
Jeżeli dobrze rozumiem to wg. Wystawienie faktury jest właściwie operacją modyfikującą istniejącą fakturę, więc jest zmianą wartości pola czyWystawiona na tak, a następnie fakturka powinna być utrwalona w bazie.

Nowa faktura to obiekt nowy a nie "zmieniony" ??? czyż nie?

Temat: Model dziedziny a operacje

Pawel K.:
Generalnie obiekt biznesowy,czyli nasza faktura rozebrana na drobne powinien byc obslugiwany przez jakas osobna klase, ktora wykonuje operacje na tym obiekcie.

Wiadomo, ze obiekt biznesowy powinien sam moc obliczyc np. kwote calkowita faktury, ale sam w sobie nie powinien soba zarzadzac. Traktowac go nalezy jako dane w pewnej formie.

Klasa zarzadzajaca moze robic cokolwiek z obiektem biznesowym. Transformowac go do dowolnej postaci, robic raporty z listy obiektow itp. Nawet z pozoru proste zadanie jak zatwierdzenie faktury moze byc calkiem skomplikowanym w praktyce(np. chec zapisac dodatkowa kopie read-only calej faktury, zwalidowac fakture i wypluc ewentualne bledy itd.).

Pozniej, jezeli klient zechce raportow to mozna po prostu do takeigo zarzadzcy faktur dopisac kod zwaracajacy interesujace nas dane.

Oczywiscie jest to jedno z rozwiazan, ktorych jest na pewno wiecej ;)

Ja osobiście skłaniam się właśnie do modelu w którym obiekty biznesowe nie robią nic poza "byciem" i pamiętaniem wiedzy o sobie (np. status itp..) zaś operacje na nich (mogące być specyfika danej firmy lub branży) będą skupione w osobnej klasie zarządzającej, pozwoli to np. zmienić sposób wystawiania czy zatwierdzania dokumentu w przyszłości nie dotykając np. samej faktury jako klasy (zakładając, że jej postać jest stałą uzależniona od przepisów).

Zaletą tego podejścia jest także to, że sięgnięcie do dowolnej historycznej faktury nie wymaga odwoływania się do żadnych innych obiektów, raporty są proste i szybkie kosztem pewnej redundancji ale to (koszt pamięci) już przestaje być problemem.

Temat: Model dziedziny a operacje

Przeczytalem kilkanascie ksiazek, podejrzalem ilestam projektow i z samemu cos tak zaimplementowalem. Wlasnie na tej podstawie wnioskuje, ze jak jakas logika manipulujaca obiektami biznesowymi jest w nich samych to z reguly po jakims czasie zostaje przenoszona do warstwy logiki.

Wszystko zalezy na jakim poziomie abstrakcji sie operuje.

Temat: Model dziedziny a operacje

Jarek Żeliński:
Podczas jednego z moich projektów pojawił się dylemat w zespole: załóżmy, że np. fakturę "rozebrałem" na drobne klejąc ja jako kompozycję jej wystawcy, kontrahenta, pozycji zafakturowanych, stosownych dat itp. i teraz pytanie: operacja wystaw fakturę powinna być w klasie "zbierającej to do kupy" czy jednak powinna powstać klasa WystawiaczFaktur (a może ZarządcaFaktur bo ktoś musi robić raporty), która ma między innymi operacje nowa faktura?

Witam

Mógłbyś napisać co dokładnie powinna robić funkcjonalność "wystawienie faktury"? (W sensie coś więcej niż "wystawiać fakturę:))

Ps. ZarządcaFaktur "śmierdzi" tu troszeczkę FackturaManagerem czyli klasą która łątwo może zmaienić sie w "BLOBa" i zacznie wchłaniać cały system. Prędzej by tutaj pasował RaporterFaktur bądź UsługaRaportowa według DDD.

pzdr

Temat: Model dziedziny a operacje

Pawel K.:
Przeczytalem kilkanascie ksiazek, podejrzalem ilestam projektow i z samemu cos tak zaimplementowalem. Wlasnie na tej podstawie wnioskuje, ze jak jakas logika manipulujaca obiektami biznesowymi jest w nich samych to z reguly po jakims czasie zostaje przenoszona do warstwy logiki.

Wszystko zalezy na jakim poziomie abstrakcji sie operuje.

Wiesz moim zdaniem zależy jaka to Logika. Jeśli np. masz klasę domenową Produkt i na podstawie stanu magazynowego masz określić dostępność tego produktu (niska,średnia,wysoka) to umieściłbyś tę funkcjonalność jako metodę obiektu czy też jako odrębną usługę?

pzdr

Temat: Model dziedziny a operacje

Paweł W.:

Jarek Żeliński:
Podczas jednego z moich projektów pojawił się dylemat w zespole: załóżmy, że np. fakturę "rozebrałem" na drobne klejąc ja jako kompozycję jej wystawcy, kontrahenta, pozycji zafakturowanych, stosownych dat itp. i teraz pytanie: operacja wystaw fakturę powinna być w klasie "zbierającej to do kupy" czy jednak powinna powstać klasa WystawiaczFaktur (a może ZarządcaFaktur bo ktoś musi robić raporty), która ma między innymi operacje nowa faktura?

Witam

Mógłbyś napisać co dokładnie powinna robić funkcjonalność "wystawienie faktury"? (W sensie coś więcej niż "wystawiać fakturę:))

No wystawienie faktury to powstanie nowej: stan początkowy to wiem na co i komu ta faktura będzie wystawiona a stan końcowy to istniejący obiekt "Faktura" opisany pewna kompozycja obiektów składowych.

Ps. ZarządcaFaktur "śmierdzi" tu troszeczkę FackturaManagerem czyli klasą która łątwo może zmaienić sie w "BLOBa" i zacznie wchłaniać cały system. Prędzej by tutaj pasował RaporterFaktur bądź UsługaRaportowa według DDD.

Hm... myślałem tak: faktury już wystawione to będzie kolekcja obiektów klasy Faktura. Na bazie wzorca Domain Model zawierającego obiekty reprezentujące dane i obiekty reprezentujące reguły biznesowe rozdzielił bym faktury od tego jak je wystawiać, zatwierdzać itp... Raportowanie chyba w ogóle warto potraktować jako osobny "problem" (ostatnio praktykuje rozdzielenie danych operacyjnych od raportowych, w pewnym sensie wbudowuje w aplikacje "hurtownie danych" gdzie trzymane dane o faktach związanych z obiektami modelu dziedziny). Historia zmian jest zawarta w obiektach tzn. Faktura jako kolekcja zawiera obiekt DaneNabywcy i nawet ten nabywca sobie później zmieni adres lub nazwę to nie dotknie to już istniejącego obiektu Faktura. Rozwiązanie to cechuje się pewną nadmiarowością ale ja już jakiś czas temu odpuściłem sobie normalizację i unikanie redundancji bo bardzo to komplikuje logikę danych a zysk nie wart kosztów.

Faktura była by tu obiektem BusinesObject (wzorzec Go4), nowa faktura powstawał by z użyciem wzorca Fabryka.

Temat: Model dziedziny a operacje

Paweł W.:

Pawel K.:
Przeczytalem kilkanascie ksiazek, podejrzalem ilestam projektow i z samemu cos tak zaimplementowalem. Wlasnie na tej podstawie wnioskuje, ze jak jakas logika manipulujaca obiektami biznesowymi jest w nich samych to z reguly po jakims czasie zostaje przenoszona do warstwy logiki.

Wszystko zalezy na jakim poziomie abstrakcji sie operuje.

Wiesz moim zdaniem zależy jaka to Logika. Jeśli np. masz klasę domenową Produkt i na podstawie stanu magazynowego masz określić dostępność tego produktu (niska,średnia,wysoka) to umieściłbyś tę funkcjonalność jako metodę obiektu czy też jako odrębną usługę?

pzdr

Jezeli bylaby to metoda w klasie domenowej to musiala by zawiedac jakeis polaczenia do bazy, ewentualnie przekazyac jakos to polaczenie. Pierwsze rozwiazanie odpada a drugie i tak tworzy usluge.

Najbardziej stowrzyl bym usluge typu DostepnoscProduktu(typ) wywolywana z typem produktu jako parametrem i zwracaja stan.

Temat: Model dziedziny a operacje

Jeśli np. masz klasę domenową Produkt i na podstawie stanu magazynowego masz określić dostępność tego produktu (niska,średnia,wysoka) to umieściłbyś tę funkcjonalność jako metodę obiektu czy też jako odrębną usługę?

a co oznacza ta "dostępność"?

Temat: Model dziedziny a operacje

Pawel K.:

Paweł W.:

Pawel K.:
Przeczytalem kilkanascie ksiazek, podejrzalem ilestam projektow i z samemu cos tak zaimplementowalem. Wlasnie na tej podstawie wnioskuje, ze jak jakas logika manipulujaca obiektami biznesowymi jest w nich samych to z reguly po jakims czasie zostaje przenoszona do warstwy logiki.

Wszystko zalezy na jakim poziomie abstrakcji sie operuje.

Wiesz moim zdaniem zależy jaka to Logika. Jeśli np. masz klasę domenową Produkt i na podstawie stanu magazynowego masz określić dostępność tego produktu (niska,średnia,wysoka) to umieściłbyś tę funkcjonalność jako metodę obiektu czy też jako odrębną usługę?

pzdr

Jezeli bylaby to metoda w klasie domenowej to musiala by zawiedac jakeis polaczenia do bazy, ewentualnie przekazyac jakos to polaczenie. Pierwsze rozwiazanie odpada a drugie i tak tworzy usluge.

Najbardziej stowrzyl bym usluge typu DostepnoscProduktu(typ) wywolywana z typem produktu jako parametrem i zwracaja stan.

Witam

Ta metoda musiałaby mieć dostęp do bazy tylko coś w podobie do Active Record implementował.

Możesz mieć obiekt domenonowy w postaci zwykłej klasy która została zainicjalizowana przez np. jakiegoś ORMa.

Przykładowy pseudokod :

if(quantity>10)

   return Availability.HIGH

else

   return Availability.LOW

i ta metoda moim zdaniem jak najbardziej powinna się znaleźć w klasie Produktu gdyż określa ona jego stan w kontekście domeny (czyli możemy spodziewać się ,iż ta klasa zwróci nam informacje odnośnie swojej dostępności na podstawie4 swojego stanu).

Natomiast funkcjonalność "usuń z magazynu" umieściłbym w komponencie Magazyn lub UsługaMagazynowa gdyż sformuowanie "Produkt usuwa się sam z magazynu" jest bezsensowne.

pzdr

Temat: Model dziedziny a operacje

Jarek Żeliński:

Jeśli np. masz klasę domenową Produkt i na podstawie stanu magazynowego masz określić dostępność tego produktu (niska,średnia,wysoka) to umieściłbyś tę funkcjonalność jako metodę obiektu czy też jako odrębną usługę?

a co oznacza ta "dostępność"?

W tym przypadku byłaby to informacja czy to,ze mamy 50 sztuk produktu w magazynie to dużo czy mało.

Temat: Model dziedziny a operacje

Paweł W.:

a co oznacza ta "dostępność"?

W tym przypadku byłaby to informacja czy to,ze mamy 50 sztuk produktu w magazynie to dużo czy mało.

znaczy się atrybut "stan_minimalny" klasy Produkt produktu? (w sztukach lub procentach)??? Możliwe, ze atrybut ten byłby osobnym obiektem value_object?

Temat: Model dziedziny a operacje

.Ten post został edytowany przez Autora dnia 01.08.16 o godzinie 21:46

Temat: Model dziedziny a operacje

Jarek Żeliński:

Paweł W.:

a co oznacza ta "dostępność"?

W tym przypadku byłaby to informacja czy to,ze mamy 50 sztuk produktu w magazynie to dużo czy mało.

znaczy się atrybut "stan_minimalny" klasy Produkt produktu? (w sztukach lub procentach)??? Możliwe, ze atrybut ten byłby osobnym obiektem value_object?

Tak wydaje mi się ,że zakresy dostępności można by przedstawić/stworzyć jako value object.

Temat: Model dziedziny a operacje

Paweł W.:
Ok ale kiedy możesz powiedzieć ,że faktura jest wystawiona?
Gdy zostanie zapisana do bazy ze statusem "kompletna" czy coś podobnego?

Jeżeli będzie to obiekt statusowy ze zdefiniowanymi statusami i przejściami (maszyna przejść stanów) to chyba załatwia sprawę?

Zakładam ,że jeśli na obiekcie Faktura ustawisz wszystkie dane to nie jest ona jeszcze wystawiona gdyż wtedy nie byłoby żadnej metody "wystawFakturę".

wypełnienie klepnięcie "formatki" stworzy obiekt Faktura z początkowym statusem "utworzona", kolejne statusy to reguły biznesowe powiązane z tym obiektem....

Hm... myślałem tak: faktury już wystawione to będzie kolekcja obiektów klasy Faktura. Na bazie wzorca Domain Model zawierającego obiekty reprezentujące dane i obiekty reprezentujące reguły biznesowe rozdzielił bym faktury od tego jak je wystawiać, zatwierdzać itp...

Moim zdaniem poprawne podejście. Faktura sama siebie nie wystawia ani nie zatwierdza.

Faktura była by tu obiektem BusinesObject (wzorzec Go4), nowa faktura powstawał by z użyciem wzorca Fabryka.

Dlaczego powstawałby z użyciem wzorca fabryka:>?

mogłem pomylić nazwę wzorca, chodzi mi o wzorzec, który do stworzenia nowego obiektu korzysta z "pustego obiektu" jako matrycy do kalkowania, konfiguracja takiego systemu polega na stworzeniu (zmianie) tego wzorca wtedy reszta kodu (między innymi tworząca nowe faktury) pozostanie niezmieniona mimo zmiany zawartości (struktury) faktury.

Temat: Model dziedziny a operacje

Jarek Żeliński:

Paweł W.:
Ok ale kiedy możesz powiedzieć ,że faktura jest wystawiona?
Gdy zostanie zapisana do bazy ze statusem "kompletna" czy coś podobnego?

Jeżeli będzie to obiekt statusowy ze zdefiniowanymi statusami i przejściami (maszyna przejść stanów) to chyba załatwia sprawę?

Zakładam ,że jeśli na obiekcie Faktura ustawisz wszystkie dane to nie jest ona jeszcze wystawiona gdyż wtedy nie byłoby żadnej metody "wystawFakturę".

wypełnienie klepnięcie "formatki" stworzy obiekt Faktura z początkowym statusem "utworzona", kolejne statusy to reguły biznesowe powiązane z tym obiektem....

Ok na tyle na ile zrozumiałem problem to według mnie mniej więcej powinno być tutaj coś takiego:

UsługaFakturowania.wystawFakturę

...

faktura.ustawOdpowiednieRegułyBiznesowe

zapisywaczDoBazy.zapisz(faktura)

...

Na tyle na ile zrozumiałem.

pzdr