Я откуда знаю)

Не, дичь какая-то это ddd XD

а где это написано, что по ddd нельзя service создавать?

А смысл в сервисе как хранилище бизнес логики, если по ддд она должна храниться в VO и/или aggregate root?

а как же сервисный слой?:D

Сервисный слой нужен не для хранения бизнес логики, а для предоставления API для внешних потребителей. Создавать сервис ради наличия этого самого слоя? Потому что так принято?

Всё опять сводится к тому, кто что под сервисом подразумевает. Привычные Anemic сервисы в ддд не принято использовать, и даже если и есть что то похожее, то это фасад для потребителей или anti corruption layer

Сервисный слой нужен не для хранения бизнес логики, а для предоставления API для внешних потребителей. Создавать сервис ради наличия этого самого слоя? Потому что так принято?

"сервисный слой" понятие настолько обширное что обобщать настолько не очень хорошо

А смысл в сервисе как хранилище бизнес логики, если по ддд она должна храниться в VO и/или aggregate root?

Эванс приводил примеры когда отдельные бизнес правила выносятся в отдельные сервисы. Это просто объекты в конце концов.

это просто еще одни экторы, некоторые отвечают за инфраструктуру а некоторые за бизнес логику

Бизнес правила? Ты имеешь ввиду классы вроде Specification, strategy и т.п.?

НО это не значит что ВСЯ логика должна быть в сервисах - большинство все же в сущностях

Бизнес правила? Ты имеешь ввиду классы вроде Specification, strategy и т.п.?

у меня есть чудный сервис под названием MerchantLimitCalculator. Потому что нет ни одной сущности у которой есть вся инфа.

и у сущности мерчанта есть метод

Calculator это не сервис))

дай свое определение сервиса

Это полноценный объект с состоянием и поведением)

сервис это объект с состоянием?

фу фу фу

"сервисный слой" понятие настолько обширное что обобщать настолько не очень хорошо

Именно потому что сервис не конкретен и возникают проблемы

ну то есть иногда надо - но лучше делать их stateless

Именно потому что сервис не конкретен и возникают проблемы

давай по другому. Все есть объект.

и нет никаких сервисов, сервисного слоя и т.д.

есть слой бизнес логики, есть слой инфраструктурный

и все

Это полноценный объект с состоянием и поведением)

состояние тут лишнее ж

как его синхронизировать то?

Не, дичь какая-то это ddd XD

почитай Эванса а не слушай всяких в чатиках. А потом уже после прочтения можно попытаться разбираться

состояние тут лишнее ж

Это было определение калькулятора а не сервиса

:)

почитай Эванса а не слушай всяких в чатиках. А потом уже после прочтения можно попытаться разбираться

Он вряд ли поймет

Это было определение калькулятора а не сервиса

у меня есть сервис - калькуляторо. Он лазает в базу. опрашивает заказы мерчанта и т.д.

Он вряд ли поймет

там со второго раза обычно доходит, но суть в том что прочитать всеравно надо хотя бы один раз

это книги из разряда "ты можешь это не юзать но ознакомиться обязан"

Ну если так, то согласен Но люди ж разные бывают) Вдруг он вообще ничерта не будет пониматьс с самого начала и сгорит?) Он забросит книгу)

Смотритие, есть предмет (русский язык) есть класс конкретной программы (русский язык в мгу, 1 семестр 2017, у группы ис-17) также в базе хранятся лекци (номер лекции, дата число и время). Программа считается законченной когда щаканчивается последняя лекция. В каком классе должен быть метод isStudyProgrammFinished?

Это было определение калькулятора а не сервиса

повторю вопрос - чем калькулятор - не сервис? Допустим мы изолировали доступ в базу другим сервисом и юзаем его как зависимость. Допустим нам что бы посчитать лимит надо узнать сколько мы напродавали в прошлом месяце, еще какие-то свои конфиги почитать и спросить внешний сервис о реджектах транзакций. И на каждое это действие у нас есть инфраструтурные сервисы. Почему калькулятор, который регламентирует бизнес правила и считает дела не является сервисом?

у меня есть сервис - калькуляторо. Он лазает в базу. опрашивает заказы мерчанта и т.д.

В базу лазить из домена, это не ддд. Вроде как есть такая абстракция как репозиторий, которая возвращает рут или выполняет кастомный запрос и возвращает вэлью обжект

В базу лазить из домена, это не ддд. Вроде как есть такая абстракция как репозиторий, которая возвращает рут или выполняет кастомный запрос и возвращает вэлью обжект

лазить в базу через гейтвей который лежит на границе между двумя слоями - очень даже DDD. Инверсия зависимостей тамвсякая и т.д.

В базу лазить из домена, это не ддд. Вроде как есть такая абстракция как репозиторий, которая возвращает рут или выполняет кастомный запрос и возвращает вэлью обжект

допустим у нас есть репозиторий который возвращает вэлью обджект

и его юзает наш калькулятор

повторю вопрос - чем калькулятор - не сервис? Допустим мы изолировали доступ в базу другим сервисом и юзаем его как зависимость. Допустим нам что бы посчитать лимит надо узнать сколько мы напродавали в прошлом месяце, еще какие-то свои конфиги почитать и спросить внешний сервис о реджектах транзакций. И на каждое это действие у нас есть инфраструтурные сервисы. Почему калькулятор, который регламентирует бизнес правила и считает дела не является сервисом?

У тебя сущность не должна знать о бд

Смотритие, есть предмет (русский язык) есть класс конкретной программы (русский язык в мгу, 1 семестр 2017, у группы ис-17) также в базе хранятся лекци (номер лекции, дата число и время). Программа считается законченной когда щаканчивается последняя лекция. В каком классе должен быть метод isStudyProgrammFinished?

В классе лекции )

У тебя сущность не должна знать о бд

так она и не знает) потому у меня есть сервис - калькулятор

Леккция ведь заканчивается

Она должна содержать чистую логику

Она должна содержать чистую логику

всю "грязь" мы изолируем, это не вопрос.

вопрос в том - почему ты считаешь что калькулятор, это не сервис

повторю вопрос - чем калькулятор - не сервис? Допустим мы изолировали доступ в базу другим сервисом и юзаем его как зависимость. Допустим нам что бы посчитать лимит надо узнать сколько мы напродавали в прошлом месяце, еще какие-то свои конфиги почитать и спросить внешний сервис о реджектах транзакций. И на каждое это действие у нас есть инфраструтурные сервисы. Почему калькулятор, который регламентирует бизнес правила и считает дела не является сервисом?

Всегда так делаю, и в тестах можно подменить зависимости. Не понимаю, почем так делать не стоит.

В классе лекции )

Так она нихуя не знает про то что она часть курса

Сейчас жто в кллассе курсСервис

Сейчас жто в кллассе курсСервис

а почему не просто "сущность курс"?

В Который в свою очередь инджектится сервис лекций

Так она нихуя не знает про то что она часть курса

Ну хз тогда

Вон в сервисе лекций заканчивай )

а почему не просто "сущность курс"?

Ну вообще так на проекте у нас

Сущности эт только ентити

Сущности эт только ентити

тафталогия. энтити и есть сущности. У тебя это data model.

Сущности эт только ентити

Не в ддд)

А не будет ли жирная дата модель?

Можешь разбить если хочешь

Инкапсуляцию забацай и все

Зато не бледная)

А не будет ли жирная дата модель?

если у тебя в data model появляется бизнес логика, и стэйт не вываливается наружу (нет геттеров сеттеров) - то она уже domain model

Не в ддд)

Я знаю, но я не могу понять в какаие классы логику выносить если не в сервер

Вы все про ддд общаетесь?

Я знаю, но я не могу понять в какаие классы логику выносить если не в сервер

почитай про "Информационный Эксперт"

ERROR: S client not available

Сейчас сервис прос т свалка методов для сущности по факу

Я хочу победить это

Сейчас сервис прос т свалка методов для сущности по факу

Без систематизауии

Я знаю, но я не могу понять в какаие классы логику выносить если не в сервер

Лучшее место для логики это VO, потом уже сущности и aggregate root

Я хочу победить это

почитай про GRASP, может поможет

Лучшее место для логики это VO, потом уже сущности и aggregate root

а потом сервисы))

Лучшее место для логики это VO, потом уже сущности и aggregate root

что такое VO - ?

что такое VO - ?

Value Object

аа все

Что такое UB лучше скажите

а потом сервисы))

?

в целом DDD - он про единый язык. А все остальное легко покрывается GRASP и SOLID

Лучшее место для логики это VO, потом уже сущности и aggregate root

например вот это утверждение это прямое следствие такой штуки как "информационный эксперт"

Серега, ты вспомнил кто grasp замутил?)

Value Object

И как назвать класс

Серега, ты вспомнил кто grasp замутил?)

Крэйг Ларман. Не знаю че затупил так. Я чет себе пометку забыл поставить(

Например Address)

И как назвать класс

а что он представляет?

И как назвать класс

названия классов должны отображать твою бизнес модель

У меня будет lectionEntity lextionValueObject

У меня будет lectionEntity lextionValueObject

убери эти бесполезные суфиксы

Lection и LectionDuration например

У меня будет lectionEntity lextionValueObject

Папка Entities чтобы прям для наглядности (раз любишь писать Entity )

первое сущность - конкретная лекция, второе - VO которое описывает длительность лекции например

ну то есть суффиксы - это рак

Папка Entities чтобы прям для наглядности (раз любишь писать Entity )

так себе идея (

Папка Entities чтобы прям для наглядности (раз любишь писать Entity )

очень плохая идея

так себе идея (

Почему? @fes0r

ну то есть суффиксы - это рак

Вот я это и пытаюсь понять

Вот я это и пытаюсь понять

пойди от обратного. Твои названия должны отражать что представляют объекты. А не их тип. Это детали которые никому не интересны. Точно так же структура директорий должна показывать что происходит а не из какого типа вещей состоит проект.

ну то есть суффиксы - это рак

не всегда

пойди от обратного. Твои названия должны отражать что представляют объекты. А не их тип. Это детали которые никому не интересны. Точно так же структура директорий должна показывать что происходит а не из какого типа вещей состоит проект.

Такк объекты по факту нихуя не предстпвляют в проекте моем