Logika w encjach?

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

3

Encje JPA =/= encje w rozumieniu DDD.

0
CountZero napisał(a):

Encje JPA =/= encje w rozumieniu DDD.

? to czym sa w rozumieniu DDD?

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?

0

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


@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;
	}
}
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ć 

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

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

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?;)

0

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

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.

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ę.

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.

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).

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ę.

0

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

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

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.

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

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.

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.

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 ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1