Logika w encjach?

Logika w encjach?
ME
  • Rejestracja:ponad 7 lat
  • Ostatnio:prawie 3 lata
  • Postów:47
0

Co sadzicie na ten temat? Jedni uważają, że to jest najgorsze zło.
Zaś drudzy popieraja?

DDD mówi że logika w encjach powinna być implementowana tak bardzo na ile jest to możliwe w encjach/vo.

*nie wiedziałem w jakim dziale utworzyć temat, jak coś prosze o przeniesienie

CountZero
  • Rejestracja:prawie 8 lat
  • Ostatnio:12 miesięcy
  • Postów:262
3

Encje JPA =/= encje w rozumieniu DDD.

Shalom
Amen.
ME
  • Rejestracja:ponad 7 lat
  • Ostatnio:prawie 3 lata
  • Postów:47
0
CountZero napisał(a):

Encje JPA =/= encje w rozumieniu DDD.

? to czym sa w rozumieniu DDD?

CountZero
  • Rejestracja:prawie 8 lat
  • Ostatnio:12 miesięcy
  • Postów:262
0

Raczej czym są encje w rozumieniu JPA - one tylko mapują dane z bazy danych na obiekty javowe. Encje DDD są obiektami domenowymi na których wykonywana jest logika biznesowa. Czemu logika biznesowa ma być przywiązana do konkretnego typu bazy danych? A jak zmienisz bazę z SQL na NoSQL, lub dane na przykład będą pochodzić z zewnętrznego serwisu, to cała logika zapisana w encji JPA idzie do kosza?

ME
  • Rejestracja:ponad 7 lat
  • Ostatnio:prawie 3 lata
  • Postów:47
0

W takim razie.. Jest to sample entity napisana kierujac sie DDD, moze nie ma tu nie wiadomo jakiej logiki, ale jednak cos jest;]

Kopiuj

@Value
@EqualsAndHashCode(of = "id", callSuper = false)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class Order extends AbstractAggregateRoot<Order> {

	UUID id;
	List<LineItem> lineItems;
	@Wither(AccessLevel.PRIVATE) Status status;

	public static Order newOrder() {
		return new Order(UUID.randomUUID(), new ArrayList<>(), Status.PLACED);
	}

	public Order add(ProductInfo product, long quantity) {

		if (status == Status.COMPLETED) {
			throw new IllegalStateException("Order already completed.");
		}

		lineItems.stream() //
				.filter(it -> it.hasProductNumber(product.getProductNumber())) //
				.findFirst() //
				.map(it -> it.addAmount(quantity)) //
				.orElseGet(() -> {

					LineItem item = LineItem.of(product, quantity);
					lineItems.add(item);

					return item;
				});

		return this;
	}

	public Order complete() {

		Order order = withStatus(Status.COMPLETED).andEventsFrom(this);

		return order.andEvent(OrderCompleted.of(order));
	}

	private enum Status {
		PLACED, COMPLETED;
	}

	@Getter
	@AllArgsConstructor
	public static class LineItem {

		private final ProductNumber productNumber;
		private final BigDecimal price;
		private final String description;
		private Long quantity;

		public static LineItem of(ProductInfo info, Long quantity) {
			return new LineItem(info.getProductNumber(), info.getPrice(), info.getDescription(), quantity);
		}

		boolean hasProductNumber(ProductNumber number) {
			return this.productNumber == number;
		}

		LineItem addAmount(Long delta) {

			this.quantity = this.quantity + delta;

			return this;
		}
	}

	@Value
	@RequiredArgsConstructor(staticName = "of", access = AccessLevel.PRIVATE)
	public static class OrderCompleted {
		Order order;
	}
}
danek
  • Rejestracja:ponad 10 lat
  • Ostatnio:7 miesięcy
  • Lokalizacja:Poznań
  • Postów:797
2

Encja w JPA - obiekt który zapisujesz do bazy danych
Encja w DDD - obiekt biznesowy modelujący procesy biznesowe

To są dwa różne pojęcia i nie powinno się ich mylić 


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.
ME
  • Rejestracja:ponad 7 lat
  • Ostatnio:prawie 3 lata
  • Postów:47
0
danek napisał(a):

Encja w JPA - obiekt który zapisujesz do bazy danych
Encja w DDD - obiekt biznesowy modelujący procesy biznesowe

To są dwa różne pojęcia i nie powinno się ich mylić 

to pewnie dlatego, bo w przykladzie ktory podeslalem uzyte jest mongodb, a nie jakakolwiek sqlowa baza i jpa

baant
  • Rejestracja:ponad 11 lat
  • Ostatnio:3 miesiące
  • Lokalizacja:Wrocław
  • Postów:524
2

Nie ma znaczenia czy jest to mongo czy baza sqlowa. To wciąż całkiem inne pojęcia. Encja domenowa nie powinna nic wiedzieć o persystencji a encja bazodanowa się na tej persystencji opiera

edytowany 1x, ostatnio: baant
ME
  • Rejestracja:ponad 7 lat
  • Ostatnio:prawie 3 lata
  • Postów:47
1
baant napisał(a):

Nie ma znaczenia czy jest to mongo czy baza sqlowa. To wciąż całkiem inne pojęcia. Encja domenowa nie powinna nic wiedzieć o persystencji a encja bazodanowa się na tej persystencji opiera

to jak wyglada taka encja domenowa???

ja zauwazylem ze z tym ddd to co kod to obyczaj xDD

https://github.com/ChristophKnabe/spring-ddd-bank , tu gosciu pisze ze chcial zastosowac ddd,
po czym pozniej w (jak mam rozumiec) encjach jpa/bazodanowych napieprza sobie repository, fetchuje dane etc.

tak samo przyklad powyzej z mongo, twierdzicie ze to nie ddd, czyli oliver gierke to generalnie nieogar?;)

edytowany 3x, ostatnio: Merylin
baant
nie widze mongo w kodzie który podałeś wyżej
ME
mozesz zaufac mi na slowo ze jest embedded mongo, nie musi byc zdefiniowane @Document
danek
  • Rejestracja:ponad 10 lat
  • Ostatnio:7 miesięcy
  • Lokalizacja:Poznań
  • Postów:797
0

Encja domenowa -> tam gdzie są jakieś operacje, logika, cokolwiek
Encja JPA -> Struktura danych, bez metod poza getterami i setterami


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ
Haste - mała biblioteka do testów z czasem.
ME
czyli co, przykladowo majac Customer'a, chcac byc DDD powinienem utworzyc klase 'CustomerJPA' ktora bedzie encja i 'Customer' w ktorym bedzie logika? :D
danek
tak, dlatego DDD nie wszędzie ma sens
ME
moze w tym przykladzie z mongo gierke nie chcial byc ddd, przez to wsadzil jakas tam logike w Order, ale... czy zrobil to po to zeby przyklad byl zwiezly i prosty/nie chcialo mu sie tego rozbijac na jakies managery/creatory. czy moze jednak takie rozwiazanie jest jak najbardziej okej? (bo z tego co pisal @CountZero w encjach bazodanowych nie powinno byc logiki), nie miej jednak on takie cos zastosowal :v
CountZero
Nie wypowiem się o przykładzie, bo nie znam baz NoSQL. W encjach JPA trzymałbym się jednak z daleka od logiki biznesowej.
Bambo
  • Rejestracja:ponad 10 lat
  • Ostatnio:8 miesięcy
  • Postów:779
0

Sam ten temat wałkowałem kilka miechów i wychodzi na to, że praktycznie wszędzie na konferencjach czy jakiś tutkach jak np. bottega encje domenowe są i tak rozbudowywane o adnotacje jpa czy mongo i wychodzi, że to to samo. Nie znalazłem przykładu, gdzie to jest oddzielnie. A jak zrobłem tak, że miałem ObjectDto -> ObjectDDD -> ObjectJPA i w drugą stronę to J. Nabrdalik odpisał mi, że bez sensu tworzyć aż takie abstrakcje, także bądź tu mądry.

jarekczek
  • Rejestracja:prawie 8 lat
  • Ostatnio:ponad 4 lata
  • Lokalizacja:Siemianowice Śląskie
  • Postów:500
0

Dyskusję nad DDD powinno się zaczynać od czytałem/nie czytałem Evansa. Jeżeli ktoś nie czytał, to nie za bardzo mi się chce streszczać. A jak czytał, to chętnie podyskutuję.


Przeważnie ignoruję niezarejestrowanych użytkowników.
baant
A jak ktoś czytał Vernona?
jarekczek
Rozumiem, że to coś w stylu Nowego Testamentu. To chyba może być :)
jarekr000000
  • Rejestracja:ponad 8 lat
  • Ostatnio:około 4 godziny
  • Lokalizacja:U krasnoludów - pod górą
  • Postów:4708
2

Czytałem Evansa DDD, dawno. Nic nie zrozumiałem. Minimalnie zrozumiałem streszczenie :-) (było jakieś popularne, zapomniałem).

Vernona czytałem kilka razy, nawet niedawno (i nawet kupiłem polską wersję - polecam do śmiechu - tłumaczenia jest mega śmieszne).
Vernona nie zrozumiałem tylko trochę mniej.

Posługuje się pojęciami z DDD, Aggregat, Root Aggregat, itd, nawet BoundedContext, ale tak ogólnie to nie wiem o co chodzi.

Na wykładach naszych mistrzów DDD Sobótka, Michaluk, Szydło byłem wiele razy.
Wykłady bardzo mi się podobały. Rozumiałem o czym były, brałem aktywny udział,
ale nie wiem co to jest DDD.
Ile razy widzę kod pisany w DDD... to mam wrażenie, ze kogoś powaliło. Ja rozumiem, że przykłady to przeiżynierowane - bo małe.... ale szczerze, jak widać przeinżynierowanie na małym kodzie, to tylko boję się co będzie w większym.

Tym niemniej cały czas mam wrażenie, że w tym DDD coś może jest, za dużo terminów wykuli, z których każdy z osobna jest jakoś przydatny. Tylko w całośc mi się to nie spina.


jeden i pół terabajta powinno wystarczyć każdemu
edytowany 1x, ostatnio: jarekr000000
jarekczek
Ja po tej książce zapragnąłem zostać programistą :) A z tym nierozumieniem, to nie przesadzajmy. Historie są ciekawe i dobrze prezentują ideę. I to nie tylko mistycznego DDD, ale ogólnie programowania. To tak żeby ktoś nie pomyślał, że to jakiś stek ciężkich definicji, których nawet arcymag nie ogarnie :)
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:17 minut
  • Postów:8423
3

W ogóle ja mam wrażenie, że jak coś czytam/słucham o DDD na konferencji, czy z książki, niech to będzie Eric Evans choćby, a jak widzę realny kod, który jest "pisany w DDD", to jest niebo a ziemia. Tak jakby teoria się rozmijała z praktyką.

Ale nie, nie winię gurusów DDD czy DDD jako takiego, tylko winię ludzi, którzy wcielają w życie DDD nie rozumiejąc przesłania.

Już sam fakt, że ludzie próbują "pisać w DDD" przesądza o tym, że będzie to kupa gówna, bo ludzie po prostu pakują randomowo wzorce opisane w książkach do DDD, zamiast spojrzeć szerzej. Zaryzykowałbym opinię, że DDD bez tych wszystkich wzorców (czyli DDD bez encji, bez agregatów, bez repozytoriów itp.) dalej miałoby sens (ludzie zdają się zapominać, że DDD znaczy Domain Driven Development a nie Design Pattern Driven Development. Wtedy byłoby to DPDD). Owszem, jakieś wzorce (czy raczej "building blocks", jak to zostało opisane w książce Evansa) są być może potrzebne. Rzecz w tym, że jeśli nie te wzorce, to zawsze można wymyśleć inne.

Tak samo wzorce projektowe kojarzone zwykle z DDD można stosować również bez DDD. Przecież nazwanie klasy Entity nie oznacza wcale, że będzie to zgodne z duchem DDD. Szczególnie, że z DDD kojarzy się również wzorce, które nawet nie były chyba pierwotnie traktowane jak część DDD - CQRS, event sourcing... (w każdym razie pewno stosowanie tych wzorców nie oznacza, że coś będzie zgodne z duchem "domain driven design").

Sam nie uważam się za żadnego speca od DDD, jednak szkoda w sumie, że idea, która miała pewien potencjał (tak jak Agile choćby) zostaje zamieniona w jakiś ogromny cargo cult i bezmyślne kopiowanie modnych wzorców (co do Agile, to takim wypaczeniem i parodią Agile, stał się oczywiście Scrum, który jest w pewnym sensie zaprzeczeniem całego Agile - bo jeśli się tworzy gotowy framework do tego, "jak być zwinnym", to automatycznie przestaje być się zwinnym, jeśli się po prostu postępuje zgodnie z góry wyznaczonymi procedurami).


Aventus
  • Rejestracja:około 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:UK
  • Postów:2235
0

Ile razy widzę kod pisany w DDD... to mam wrażenie, ze kogoś powaliło. Ja rozumiem, że przykłady to przeiżynierowane - bo małe.... ale szczerze, jak widać przeinżynierowanie na małym kodzie, to tylko boję się co będzie w większym.

Całkowicie błędne podejście. To tak jakby osoba która dopiero nauczyła się wyświetlać Hello World w konsoli mówiła że metody to overengineering, w końcu można kod sobie pisać w mainie. A z metodami to trzeba przeskakiwac w kodzie i w ogóle... Przykład z metodami piszę z autopsji :)

Co do samego DDD to szczerze mówiąc nie wiem czego tu nie rozumieć, ja akurat bardzo szybko to zrozumiałem a zapewniam że żadnym geniuszem nie jestem. DDD konceptualnie jest właśnie proste, prawdziwy problem to je prawidłowo zaimplementować na większą skalę.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
jarekr000000
Btw. Hello world pisze w mainie.
Aventus
Nie rozumiem o co Ci chodzi.
YA
To zupełnie jak z konceptami OOP, agile, DevOps i masą innych. Teoria tak oczywista, że wystarczy tylko wziąć i zrobić.
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:17 minut
  • Postów:8423
0

Co do samego DDD to szczerze mówiąc nie wiem czego tu nie rozumieć,

no to jakie dasz tipy, żeby lepiej zrozumieć?


jarekczek
Jeżeli to dla kogoś łatwe i wszystko rozumie, to jak może dawać tipy? Daje się tipy do czegoś, co uważa się za trudne.
WeiXiao
@jarekczek: Bo może wszystko stało się łatwe po X, więc X jest tipem :)
LukeJL
fakt, to tak jakby rodowitego Amerykanina czy Anglika spytać o to, jak się nauczył angielskiego i czy nie ma jakichś tipów.
Aventus
  • Rejestracja:około 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:UK
  • Postów:2235
0

@LukeJL: ciezko dac jakies "tipy" zeby cos zrozumiec, skoro to po prostu... trzeba zrozumiec. Jesli ktos nie rozumie jakichs konkretnych zagadnien to trzeba by je wyjasnic- ale od tego potrzebny by byl oddzielny watek.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
hcubyc
  • Rejestracja:ponad 12 lat
  • Ostatnio:prawie 3 lata
2

Zgodzę się z Lukiem, mimo że sam piszę w DDD i uważam, że wychodzi całkiem nieźle, chociaż ideał to nie jest, jednak często spotykając się z tym co ludzie twierdzą o DDD to często porażka. Byłem raz na warsztatach z DDD i dla prowadzącego nie było nic złego w tym, że encje/agregaty miały gettery i settery, no bo fakt 'w książce było inaczej, ale kto by tak pisał'. Dzięki temu logika wyciekała do serwisów i anemiczne encje w DDD. Też nie przeszkadzało mu umieszczanie adnotacji JPA na tych encjach, bo znowu w książce było inaczej, ale tak jest szybciej. Generalnie zrozumiem, jeżeli ktoś stosuje adnotacje JPA na modelu dopóki nie ma to wpływu na model, ale potem się okazuje to co napisał Lukiem - to projekty robione w ten sam sposób, tylko dochodzą wzorce i próby modelowania, zazwyczaj mniej udane. Zresztą IMHO DDD to takie OOP na sterydach, po prostu trochę więcej zasad, parę wzorców i wsio, co innego modelowanie bounded contextów i zależności między nimi, ale to też nie jest jakiś rocket science


Limitations are limitless > ##### Ola Nordmann napisał(a)
> Moim językiem ojczystym jest C++ i proszę uszanować to, że piszę po polsku.
edytowany 2x, ostatnio: hcubyc
LukeJL
  • Rejestracja:około 11 lat
  • Ostatnio:17 minut
  • Postów:8423
0

ciezko dac jakies "tipy" zeby cos zrozumiec, skoro to po prostu... trzeba zrozumiec.
Jesli ktos nie rozumie jakichs konkretnych zagadnien to trzeba by je
wyjasnic- ale od tego potrzebny by byl oddzielny watek.

Wymigujesz się od odpowiedzi ;)

Chodziło mi o to, że ile razy widzę kod "pisany w DDD", to tyle razy mam wrażenie, że ludzie tego nie rozumieją za bardzo i po prostu przenoszą bezmyślnie rzeczy, o których przeczytali w książce. Bez głębszego zrozumienia.

Owszem, nie neguję tego, że np. ty możesz zrozumieć i dla ciebie jest to łatwe - ale nie zmienia to tego, że dla większości ludzi nie jest to łatwe i że jednak jest czego nie rozumieć, skoro efektem są potem przeinżynierowane nieskalowalne potworki zamiast prostoty i skalowalności.

DDD konceptualnie jest właśnie proste,

Z tym się zgodzę akurat. Nawet wydaje mi się, że problem wielu ludzi to komplikowanie na siłę. Najtrudniejsze w DDD jest zrozumieć, że jest to proste. Że może być proste.


Aventus
  • Rejestracja:około 9 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:UK
  • Postów:2235
0

Ależ ja się od niczego nie wymiguje, po prostu nie wiem jak te tipy miałyby wyglądać. W pełni się zgadzam z tym że kod pisany- teoretycznie- w oparciu o DDD jest często pisany bezmyślnie. Tylko że to już nie jest wina DDD samego w sobie. Poza tym mówimy o kodzie a chciałbym zaznaczyć że DDD to nie sam kod.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus
hcubyc
  • Rejestracja:ponad 12 lat
  • Ostatnio:prawie 3 lata
0

W moim poście była pomyłka - odnosiłem się do tego co napisał Luke ;) I tak, przejście nie jest łatwe, bo swego czasu (a i pewnie teraz) większość tutoriali promuje anemiczne encje, encje na twarz, mix wszystkiego, szczególnie tutoriale springowe, hibernatowe i tym podobne. Im dłużej ktoś programował w ten sposób tym cięzej będzie mu się przestawić. Tipów można dać wiele na początek, ale IMHO warto sięgnąć po red booka i zasady OOP np. enkapsulacja, prawo demeter. Ban na settery i gettery ;)


Limitations are limitless > ##### Ola Nordmann napisał(a)
> Moim językiem ojczystym jest C++ i proszę uszanować to, że piszę po polsku.
danek
i usunąć z template public
hcubyc
też, ale to już bardziej architekturalnie nie narzucałbym zbyt wiele na początek ;)

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.