23 апр 2015 19:31 | |
Сообщения:1517
|
WertLex:
Я бы так сказал:
там достаточно много простора, чтобы писать хороший код. И ровно столько же просторов, чтобы писать плохой. При этом имхо, кое чего там таки не хватает. Иногда компилятор подтупливает на сложных дженериках, очень не хватает вот прям чистых функций. Прикрутили бы какую аннотацию, чтоли. Знаю, много всего бы это задело и не так все это просто, но тем не менее. А насчет нормального функционального языка тоже не очень согласен. Имхо, вся мощь Scala в том, что она и FP и OOP одновременно. К слову, если есть какой-нибудь годный проект на примете, в котором очень удачно реализована модель предметной области, то с радостью бы посмотрел. ответил тут , что б не засорять тему оффтопом |
vimba:
То есть сам иевангилист DDD ничего не имеет против размещения логики в сервисах. И при этом заметь твой FlightBooker не относится ни к одному из трех видов доменной модели описанных Эвансом, это не сущность не сервис и не объект значение. Вводя FlightBooker ты не следуешь DDD так как логика уже отдельно данных, а именно это дэдэдэшники и считают основной его фичей, но твоё решение точно так же как и решение с помещением логики в сервис вполне практичное и работоспособное.
То есть сам иевангилист DDD ничего не имеет против размещения логики в сервисах. И при этом заметь твой FlightBooker не относится ни к одному из трех видов доменной модели описанных Эвансом, это не сущность не сервис и не объект значение. Вводя FlightBooker ты не следуешь DDD так как логика уже отдельно данных, а именно это дэдэдэшники и считают основной его фичей, но твоё решение точно так же как и решение с помещением логики в сервис вполне практичное и работоспособное.
Так Эванс пишет, что нужно делать сервис в модели:
Если существенно важный процесс или преобразование в модели не относится к ес
тественным обязанностям объекта-сущности или ЗНАЧЕНИЯ , добавьте в модель эту
операцию с отдельным интерфейсом и назовите ее СЛУЖБОЙ. Определите интерфейс
н а языке модели и сделайте имя операции элементом ЕДИНОГО ЯЗЫКА. У СЛУЖБЫ не
должно быть собственного состояния.
- Эрик Эванс. Предметно-ориентированное Проектирование , Стр. 108, ISBN 978-5-8459-1597-9 (рус.)
Как я понял, в контексте Spring MVC, нужно максимально логику в модель утрамбовывать, в том числе делать сервисы на уровне модели, а если уже никак не получается, например
нужна подгрузка объектов из других сервисов, то делать сервис Spring.
P.S. немного попутал, тут-то не совсем про Spring, смешались у меня две эти дискуссии, вот где я читал паралельно про этот вопрос:
The Biggest Flaw of Spring Web Applications