Czy powinienem umieścić logikę obliczeń w jednostce czy w warstwie biznesowej?

Ostatnio stanęło mi pytanie o to, czy należy umieścić proste obliczenia w warstwie encji, czy też encja powinna być czysta tylko do przechowywania surowych danych i pozostawić logikę obliczeń w warstwie biznesowej.

Moje pytanie brzmi więc, czy rozsądne jest zawarcie prostych obliczeń we właściwościach w klasie encji?

design-patterns

— Kata
źródło

Odpowiedzi:

To zależy od rodzaju architektury, którą chcesz.

W projektowaniu opartym na domenie utworzyłbyś model domeny, który miałby zarówno dane, jak i funkcjonalność.

Oznaczałoby to, że an Orderma właściwość (lub metodę), która zwróciłaby całkowitą cenę zamówienia na podstawie OrderLines. OrderMiałby również metodę AddOrderItem(Product product, int amount)i Orderby sprawdzić, czy nie jest już OrderLinedla danego produktu.

W takim modelu miałbyś również obiekty, które nie są rzeczywistymi bytami, takie jak Repositorydostęp do danych lub Factorytworzenie bytów. Są to tak zwane usługi domenowe. Warstwa aplikacji jest odpowiedzialna za wywołanie usług domenowych (na przykład w celu pobrania encji z bazy danych), a następnie wykona funkcjonalność na encji. Application LayerPowinny być jak najcieńsze.

To jest miły artykuł o DDD, który wyjaśnia te pojęcia bardziej szczegółowo.

Możesz także użyć modelu domeny anemicznej . Oznacza to, że twoje podmioty składają się z właściwości get / set i nie zawierają żadnego zachowania. W takim projekcie warstwa biznesowa będzie zawierać takie zachowanie, jak obliczanie Orderceny i sprawdzanie duplikatu OrderLines.

Istnieją różne opinie, czy anemiczny model domeny jest złą rzeczą. Osobiście wolę prawdziwy model domeny.

W tym artykule opisano różnice między anemicznym a nieememicznym modelem domeny.

— Wouter de Kort
źródło

Cześć Wouter, dziękuję za odpowiedź i linki. Wydaje mi się, że mam do czynienia z niewłaściwym nastawieniem, że przy użyciu modelu domeny Anemic wszystkie logiki biznesowe (nawet bardzo proste) powinny zostać umieszczone w warstwie biznesowej. Wydaje się to pozbawione sensu w niektórych przypadkach, w których logika biznesowa tak naprawdę zależy tylko od samego modelu. Na przykład właściwość jest obliczana na podstawie istniejących właściwości w modelu. Nie mogłem znaleźć rozsądnego powodu do umieszczenia logiki biznesowej, która wszystko zależy od samego modelu w warstwie biznesowej.

W anemicznym modelu domeny, ponieważ mamy zarówno klasy biznesowe, jak i encje, jak prawidłowo nazwać klasy, aby uniknąć pomyłek między nimi? Czy sugerujesz używanie sufiksów? Jeśli tak, czy możesz podać przykład?

— Kwadz

Co w przypadku DDD, jeśli logika obliczania ceny jest skomplikowana? Na przykład cena zależy od lokalizacji (podatek), informacji o użytkowniku (zniżka daty urodzenia, zniżka członkowska), kuponu, karty kredytowej (specjalna zniżka na kartę kredytową) itp. Jak możemy umieścić taką logikę w Orderklasie?

— Sher10ck

Twój agregat zamówienia powinien zawierać wszystkie te informacje potrzebne do obliczenia. Ponieważ na podstawie opisu powinien on faktycznie stanowić część agregatu. Ale jeśli logika staje się naprawdę złożona i być może trzeba ją zmienić, przekazałbym kalkulator jako obiekt konstruktorowi encji i pozwoliłbym encji użyć kalkulatora wewnętrznie do ustalenia ceny.

— burzum

Anemiczny ... biedna domena brzmi, jakby cierpiała na jakąś chorobę. Czy nie wolisz być napędzany ?! Tak!

— Matt Jenkins

Cóż, encja i obiekty biznesowe są prawie takie same, przez większość czasu. Na przykład, jeśli masz klasę produktu i chcesz odsłonić właściwość, która pobiera pewną istniejącą właściwość w klasie produktu i wykonuje pewne obliczenia, a następnie je ujawnia. W porządku jest to, że logika tworzenia tej własności pozostaje w gestii klasy.

Teraz może pojawić się pytanie, gdzie zmieścisz swoją klasę warstwy biznesowej. Wolę używać klasy warstwy biznesowej, która ma pewną logikę do rozwiązywania problemów biznesowych. Na przykład w przykładzie produktu problemem biznesowym może być naliczanie pieniędzy za pośrednictwem zewnętrznego dostawcy, takiego jak paypal.

Jedną kluczową rzeczą do zapamiętania jest to, że encja zawsze miałaby tożsamość, ale obiekt biznesowy to encja bez identyfikacji. Na przykład produkt jest bytem, ale pieniądze nie miałyby tożsamości. 1000 różnych przypadków pieniędzy byłoby takich samych.

Tak. Jeśli logika biznesowa właściwości zależy od istniejących właściwości w tym samym modelu, lepiej byłoby po prostu dodać właściwość do modelu. Pomogłoby to stracić niepotrzebną parę z warstwą biznesową dla obliczonych właściwości.