Структура приложений

 
 
 
Сообщения:1517
WertLex:
Я бы так сказал:
там достаточно много простора, чтобы писать хороший код. И ровно столько же просторов, чтобы писать плохой.
При этом имхо, кое чего там таки не хватает. Иногда компилятор подтупливает на сложных дженериках, очень не хватает вот прям чистых функций. Прикрутили бы какую аннотацию, чтоли. Знаю, много всего бы это задело и не так все это просто, но тем не менее.

А насчет нормального функционального языка тоже не очень согласен. Имхо, вся мощь Scala в том, что она и FP и OOP одновременно.

К слову, если есть какой-нибудь годный проект на примете, в котором очень удачно реализована модель предметной области, то с радостью бы посмотрел.

ответил тут , что б не засорять тему оффтопом
 
 
Сообщения:1
vimba:

То есть сам иевангилист DDD ничего не имеет против размещения логики в сервисах. И при этом заметь твой FlightBooker не относится ни к одному из трех видов доменной модели описанных Эвансом, это не сущность не сервис и не объект значение. Вводя FlightBooker ты не следуешь DDD так как логика уже отдельно данных, а именно это дэдэдэшники и считают основной его фичей, но твоё решение точно так же как и решение с помещением логики в сервис вполне практичное и работоспособное.


Так Эванс пишет, что нужно делать сервис в модели:

Если существенно важный процесс или преобразование в модели не относится к ес­
тественным обязанностям объекта-сущности или ЗНАЧЕНИЯ , добавьте в модель эту
операцию с отдельным интерфейсом и назовите ее СЛУЖБОЙ. Определите интерфейс
н а языке модели и сделайте имя операции элементом ЕДИНОГО ЯЗЫКА. У СЛУЖБЫ не
должно быть собственного состояния.

- Эрик Эванс. Предметно-ориентированное Проектирование , Стр. 108, ISBN 978-5-8459-1597-9 (рус.)

Как я понял, в контексте Spring MVC, нужно максимально логику в модель утрамбовывать, в том числе делать сервисы на уровне модели, а если уже никак не получается, например
нужна подгрузка объектов из других сервисов, то делать сервис Spring.

P.S. немного попутал, тут-то не совсем про Spring, смешались у меня две эти дискуссии, вот где я читал паралельно про этот вопрос:
The Biggest Flaw of Spring Web Applications
Изменен:15 мар 2016 22:40
 
 
Сообщения:2361
zesetup:
Если существенно важный процесс или преобразование в модели не относится к ес­
тественным обязанностям объекта-сущности или ЗНАЧЕНИЯ , добавьте в модель эту
операцию с отдельным интерфейсом и назовите ее СЛУЖБОЙ. Определите интерфейс
н а языке модели и сделайте имя операции элементом ЕДИНОГО ЯЗЫКА. У СЛУЖБЫ не
должно быть собственного состояния.

Книгу нужно читать следующим образом:
  • Первую часть где описывается подходы к проектированию, прочитать и понять.
  • Вторую часть которая описывает как это всё реализовать в коде, просто пролистать между страниц и не принимать близко к сердцу, на примеры кода можно вообще не тратить своё время, ибо они писались 12 лет назад и не выдерживают никакой критики ни человеческой, ни систем анализа кода типа sonar.

Ибо Design это про проектирование, а не про написания кода.
Изменен:16 мар 2016 05:42
 
Модераторы:wedens
Сейчас эту тему просматривают:Нет