Здравствуйте, gandjustas, Вы писали:

G>2) Сами принципы крайне туманны и не дают критерия соответствия принципам. То есть ты по коду не можешь объективно утверждать выполняется ли тот или иной принцип (за редким исключением).
G>http://gandjustas.blogspot.com/2011/08/solid.html
G>тут подробно свой взгляд описал. Предупреждаю, он сильно не соответствует тому что можно в интернетах прочитать.

помоему вы просто ниасилили
(впрочем в том посте так и написано)

Здравствуйте, licedey, Вы писали:

L>Здравствуйте, мыщъх, Вы писали:

L>Задача — выявлять прямые ссылки на видео, для скачивания.
пишется регулярками за несколько минут. можно и без регулярок на ansi c минут за десять. в принципе, парсинг промежуточных протоколов необязателен. ну на крайний случай можно сделать быструю проверку на TCP заголовок с проверкой порта.

а поставить Snort чем не вариант? он HTTP распарсит. и там даже flow сигнатуры есть. т.е. можно связать GET с ответом сервера. и есть сигнатуры для видеоконтента. уже написанные и готовые. под все мыслимые видеформаты. берем и пишем правило -- если в ответ на GET мы получили видео, то генерируем алерт такой-то.

L> В requirements такого не было. Можно еще оффтопика?
я ж не знаю ваших requirements. вам чтобы формальности были соблюдены или чтобы работало? вы упомянули лишь только 80 порт. какая-то расплывчатая формулировка. "я все чаще замечаю" (с) кот матроскин, что urlы пишутся с указанием нестандартных портов и юзер даже не в курсе, ибо для него это просто ссылка, которую нужно щелкнуть.

L> Вы четко следуете требованиям к заданию?
у меня нет опыта написания программ под заказ с целью "за отвалите вы от меня на три хвоста, как написато в ТЗ, так и работает".

> Если требуется по пунктно, но общее решение вы знаете лучше — сделаете по своему?
> Я бы тему создал, но вашего ответа будет достаточно.
буду делать так, чтобы работало. писать то, что работать не будет -- смысла не вижу никакого. и нужно намного больше деталей. т.к. если у клиента прокси, то универсальее всего написать на icap. если прокси нет, то ограничиваться одним лишь HTTP недостаточно, т.к. народ активно смотрит потоковое видео в макромедиа флэш формате, а это 1935 порт по умолчанию (пишу по памяти, могу соврать). а что на счет вебок? там же тоже далеко не 80 порт и даже не TCP. и ссылок никаких нет. а трафик нагоняют здорово.

если нужен только вывод ссылок в окошко, то готовый пример гуглиться за несколько минут. после чего останется только доработать его, чтобы он выводил ссылки только на видео, но такое решение ни фига не работает.

> Я часто замыкаюсь на задании в мельчайших подробностях, при этом общаяя картина часто
> уплывает, и получается 30 часов "как видит заказчик", вместо 10 — как вижу решение я
подробности прорабатываются по месту. сначала нужно решить концептуальные вопросы. например, на чем это вообще писать. хотите писать на си -- ваше право, но сможете ли вы это обосновать? вдруг у вас там буфер переполнится? и выяснится, что установка такого анализатора -- это бэкдор. а чтобы бэкдора не было, значит, или брать жабу (или на худой конец питона) или сразу писать отказ от всякой ответственности. гигабитный трафик спокойно обрабатывается питоном. а вот сто гигабит уже требуют ручной оптимизации и низкоуровневых языков. кстати, даже на 100 мегабит без быстрой базы данных никуда.

L> Интернет-активный. Я в курсе что у вас 6 компов и 10 сетевух. Но для общего случая пинг
L> и отзыв для определения адаптера, который ловит инет — думаю достаточно. Ну и задание большего не требовало.
грабить трафик можно кучей программ как под винду, так и под линух. и они сами разбираются какой интернет активный. если у меня на ноуте включить wifi и езернет, то работают сразу два. причем по умолчанию они работают параллельно, и при скачке большого файла он льется сразу через два. wireshark с ума сходит.

> Я максимально старался им следовать.
конечно, когда есть ТЗ, то от него можно плясать. но тогда непонятно к чему все разговоры за возможные подходы к решению задачи, если уже есть подробное описание того, что нужно делать?


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


> Даже если вы это реализуете, круто так, то сопровождать вам же. Станете рабом проекта.
а вы предлагаете отливать монолит из гранита? а потом выяснится, что на некоторых чипсетах сниффер теряет пакеты. причем теряет их много. и нужно ставить патчи. в смысле это мне их ставить нужно. более того, если я не дурак, то посмотрю какие платформы сертифицированы под грабеж трафика на tcpdump и если обнаружится пропажа пакетов (а она обнаружится), то буду лениво пинать поддержку софта и харда, закачик -- в cc и видит, что "мы работаем над этим". а если у вас монолит и пакеты теряются потому что драйвер на карту имеет баг и вендор его не фиксит, т.к. не подряжался на этой платформе сниффать траффик -- что вы будете делать?

если это не утилита за $30, то проще отдать заказчику готовый комплес в котором стоит железо и ось, выбранное с учетом специфики решаемой задачи (в данном конкретном случае, производитель железа гарантирует, что конкретный драйвер на конкетной оси гарантированно грабит трафик без проблем). исчезает сразу куча проблем. берешь коробку, втыкаешь в стойку, подключаешь питание и езернет и -- вуаля!!! оно работает через web-интерфейс и там внутри база данных, которая так же доступа удаленно. заказчик кипятком ссыт от восторга.

инсталлятор писать и тестировать его на совместимость всяко дольше, чем запихать все внутрь. ладно, пусть железо мы поставить не можем. и не надо! пошлем закзчику iso образ, который гарантированно работает под vm ware, чем решаем кучу пробем.

L> Распарсил, вывел ссылку в окошко. И вся задача
а если в окошке Over 9000 ссылок? что будет с ними делать заказчик? а как хранить историю? как делать выборку за последний час, день, месяц? как делать выборку по доменам? типа куда народ ходит больше всего и кто наш самый главный враг и убийца рабочего времени. какой локальный IP потребляет больше всех? (а тут нужно еще и ARP парсить, чтобы MAC определить или как-то еще).

опять-таки. берем wireshark. пишет дебильно простое правило поиска за три минуты. и он выводи в окошке только get'ы на видео. причем, у шарка еще и интерфейс продвинутый. и он работает на любой платформе. и обновляется по мере выхода новых версий винды. чем вам не решение?

L>Модуль у меня в первую очередь ассоциируется с файлом.
в исходных текстах модуль обычно реализуется множеством файлов. как минимум должен быть cpp/c и h.
в библиотеках в lib можно запихать в один файл 100500 модулей и линкер сам разберется какой из них вытаскивать.

> Файл кода = модуль, который другие файлы могут использовать.
давайте все-таки плясать от того, что модуль это концептуально законченный фрагмент программы типа черный ящик с документированным интерфейсом и недокументированной внутренней архитектурой.

> В модуле могут быть несколько классов, любых абстракций. Например модуль Sniffer,
> может содержать классы Parser, Listner, функции Init, Finish...Т.е. модуль — это более осязаемое,
а какое отношение имеет сниффер к парсеру? сниффер снифает трафик. парсер -- парсит. причем, парсер может (и должен!) работать не только с сетевым адаптером, но и с pcap файлами, а их можно генерировать и самому. что, кстати, полезно для тестирования. как вы будете тестировать монолитный сниффер, совмещенный с парсером? вот я хочу подать ему на вход разный мусор, сгенерированный фаззерами с целью его завалить.

L> В моей практике, большая часть задач не требует ООП. Просто бери и пиши (фриланс).
вот и я говорю, что не требует.

> Однако я следуя советам и опыту старших коллег,
> в свое время довольно увлекся ООП дизайном, анализом, UML, паттернами.
странные у вас коллеги, если в результате увлечения вы видите парсер частью сниффера. они даже работают с разными объектами. это издевательство над ООП. ну вот смотрите.

таффик = адаптер->сниффать_трафик();
список_url = траффик->парсить_траффик();

а что получается у вас: адаптер->парсить();
интересно как можно распарсить адаптер

как раз на чистом си можно запихать в один модуль разные сущности -- он все стерпит. а вот ООП визжит и сопротивляется. никак парсер не ложится в том же класс, что и сниффер. разве что сделать супер класс "программа" с методами "грабить трафик" и "парсить трафик". но в этом случае у нас будет только один класс. а один класс это не ООП

> Что-то декомпозировать — пожалуйста! Найду закономерность в 2-х несвязных сущностях.
> Решить задачу — на втором месте. А мне еще рано до архитектора...
мне, кстати, тоже рано быть архитектором и архитектором у нас работает очень умный дядька, который образно говоря проектирует самолеты, а я создаю для них движки. на уровне движка я с архитектурой еще справляюсь, но вот всю инфраструктуру самолета разработать не могу, а если даже и разработаю, то этот самолет вряд ли оторвется от земли.

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

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, licedey, Вы писали:


G>далее все пакеты выводить не надо, надо их по правилам фильтровать
G>[драйвер -> api -> фильтр пакетов -> черный ящик -> экран]
вот тут не согласен. тут все-таки не фильтр, а нечто более сложное. как миниум нужен ассемблер TCP. далее фильтровать HTTP не получится, т.к. нужно ловить GET и соответствующий ему ответ сервера (с поддержкой редиректов).

опять же -- нет прямых указаний, что это должен быть драйвер. это может быть и плагин для прокси, что избавит нас от необходимости сборки TCP и декодирования HTTP. а собирать TCP и держать сессии в памяти -- памяти не хватит. и мы неизбежно возвращаемся к необходимости базы данных. причем, быстрой.

с другой стороны -- все это уже написано. главное, знать, что заюзать. путем несложных умозаключений мы приходим к выводу, что нам подойдет любая нормальная IDS/IPS и нам останется только написать свои правила, которые пишутся на довольно простом языке.

написать нормальный ассемблер TCP -- это же сдохнуть можно. и HTTP тоже не прост.

G>[драйвер -> api -> фильтр пакетов -> форматер пактов -> экран]
G>[конфиг -> парсер конфига -> фильтры] (один раз при загрузке)
тут упущена одна важная детать. если захардокдить логику фильтрации -- то при всяком внесении изменений -- перекомпилировать всю программу. если же вынести ее в конфиг, то это не просто конфиг будет, а очень продвинутый конфиг, т.к. нам нужно описывать довольно нетривальную логику, связывающую GET и ответ сервера. тут могут быть и поля типа контент и детекция формата возвращаемых сервером данных... короче, нам нужен скриптовый язык по любому.

Здравствуйте, Lloyd, Вы писали:

L>С удовольствием почитаю. Но раз уж вы его рекомендуете, то вам несомненно не составит труда привести цитату автора, опровергающую формулировку из википедии.
Для начала можно взять более вменяемую формулировку из той же Википедии:

В центре ООП находится понятие объекта. Объект — это сущность которой можно посылать сообщения, и которая может на них реагировать, используя свои данные. Данные объекта скрыты от остальной программы

L>Факт 1: применение ООП (по википедии) приводит к " бесплодным спорам".
L>Факт 2: моделирование от поведения приводит к правильному ответу.
L>Вывод: ООП — целиком про поведение.

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

L>А так да, я согласен, "имеет смысл применять критическое мышление", причем прежде всего имеет смысл применять его к себе же.
Ну так я его к себе и применил. Я ООП начал изучать ещё по Turbo Pascal 6.0, примерно 20 лет назад. И все заблуждения, упорно насаждаемые недалёкими объясняльщиками, я честно разделял. Ровно до тех пор, пока не накопилась критическая масса фактов, противоречащих большинству мифов об ООП. Ну там, типа — "в ООП производится моделирование объектов предметной области при помощи экземпляров классов" и прочего.
Помимо мифов, существует также некоторое количество малоконструктивных подходов. В их числе и попытки моделировать иерархию классов, исходя из структуры данных. Несмотря на то, что иногда этот подход даёт более-менее приемлемые результаты, в целом он значительно чаще оставляет программиста наедине с неразрешимыми в рамках этого подхода вопросами.

Здравствуйте, Lloyd, Вы писали:

L>И примеры, которые он приводит, демонстрируют его мнение о ddd как архитектуре, а там — именно рич-модель.

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

Здравствуйте, samius, Вы писали:

S>И кроме этого, я считаю что POJO и anemic — совершенно разные вещи.

Хм... Век живи век учись Оказалось, что да, POJO не такие уж простые DTO, которые рекомендует anemic. Не знал.

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

Офтопик
Вставлю свои 5 копеек про рич и анемик: раньше я много копий ломал про них в архитектуре, сейчас надоело.

Самый простой и наглядный БЛ код работающий с БД, который мне доводилось писать и читать это ActiveRecord в руби. Он же и максимально оопшный (контроллер и бизнес объекты обмениваются сообщениями). И если производительность устраивает, я считаю, что можно спокойно положить на SRP и писать читаемый код так как удобно. И плевать с потолка на все абстракции от хранилища, ибо те же транзакции это чистая бизнес логика.

Тот же анемик довольно хорош, чтобы обеспечить достойную производительность. Но тоже имеет свои недостатки, на которые можно спокойно плевать, если на данный момент производительность важна.

Прекрасно работают оба подхода. Реальная разница только одна: в рич трудно писать производительный код, в анемик краткий и понятный код бизнес сценариев.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Lloyd, Вы писали:

L>>С удовольствием почитаю. Но раз уж вы его рекомендуете, то вам несомненно не составит труда привести цитату автора, опровергающую формулировку из википедии.
S>Для начала можно взять более вменяемую формулировку из той же Википедии:
S>

S>В центре ООП находится понятие объекта. Объект — это сущность которой можно посылать сообщения, и которая может на них реагировать, используя свои данные. Данные объекта скрыты от остальной программы

Не, раз уж взялись аппелировать к авторитету, так уж будьте добры приводить ссылки на авторитет, а не на википедию. Ведь согласно вашей формулировке там "чушь".

L>>Факт 1: применение ООП (по википедии) приводит к " бесплодным спорам".
L>>Факт 2: моделирование от поведения приводит к правильному ответу.
L>>Вывод: ООП — целиком про поведение.

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

Да, это аргумент — "Утомляет" и переходн на личности.

S>как в форум прибегает очередной знаток ООП, начитавшийся Авторитетов.

Это вы про Алана Кея?

L>>А так да, я согласен, "имеет смысл применять критическое мышление", причем прежде всего имеет смысл применять его к себе же.
S>Ну так я его к себе и применил. Я ООП начал изучать ещё по Turbo Pascal 6.0, примерно 20 лет назад.

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

S>И все заблуждения, упорно насаждаемые недалёкими объясняльщиками, я честно разделял. Ровно до тех пор, пока не накопилась критическая масса фактов, противоречащих большинству мифов об ООП. Ну там, типа — "в ООП производится моделирование объектов предметной области при помощи экземпляров классов" и прочего.
S>Помимо мифов, существует также некоторое количество малоконструктивных подходов. В их числе и попытки моделировать иерархию классов, исходя из структуры данных. Несмотря на то, что иногда этот подход даёт более-менее приемлемые результаты, в целом он значительно чаще оставляет программиста наедине с неразрешимыми в рамках этого подхода вопросами.

Только вот вывод вы из этого неправильный сделали. Ошибка — не в определении ООП как "моделирование объектов предметной области при помощи экземпляров классов", а в использовании ООП для "моделирования объектов предметной области".

Здравствуйте, Ziaw, Вы писали:

Z>Доказательства того, что DDD и anemic несовместимы здесь нет. Есть доказательство совместимости с rich model, при этом, возможна совместимость и с anemic. Основной постулат DDD — максимальное приближение модели данных к естественным сущностям в бизнесе. Я совершенно не понимаю хайпа вокруг этой аббревиатуры.

Что-то на этом пункте я завис. А в чем отличие "rich model" от "максимальное приближение модели данных к естественным сущностям в бизнесе"?

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, licedey, Вы писали:


G>>далее все пакеты выводить не надо, надо их по правилам фильтровать
G>>[драйвер -> api -> фильтр пакетов -> черный ящик -> экран]
М>вот тут не согласен. тут все-таки не фильтр, а нечто более сложное. как миниум нужен ассемблер TCP. далее фильтровать HTTP не получится, т.к. нужно ловить GET и соответствующий ему ответ сервера (с поддержкой редиректов).

М>опять же -- нет прямых указаний, что это должен быть драйвер. это может быть и плагин для прокси, что избавит нас от необходимости сборки TCP и декодирования HTTP. а собирать TCP и держать сессии в памяти -- памяти не хватит. и мы неизбежно возвращаемся к необходимости базы данных. причем, быстрой.

Сорри, я не следил за дискуссией по поводу сниффера, просто вывалил поток мыслей как дизайнить подобное приложение. Не учел те кейсы, которые вы рассматривали.

Здравствуйте, gandjustas, Вы писали:


G>Сорри, я не следил за дискуссией по поводу сниффера, просто вывалил поток мыслей как дизайнить подобное приложение. Не учел те кейсы, которые вы рассматривали.

дело в том, что если писать это по уму, то это мегапроект. фактически мы должны повторить TCP стек. а ведь ни один вендор -- ни в никсах, ни в винде, не избежал кучи ошибок. а ведь нам нужно не просто собрать TCP и поднять до уровня HTTP, но еще и отслеживать сессии, чтобы было ясно какой ответ HTTP сервера какому HTTP запросу соответствует и с какого MAC адреса он пришел.

допустим, у нас гигабит канал (в реальности у клиента может быть совокупный траффик и до ста гигабит), но даже с гигабитом -- при таймауте в несколько минут (а меньше ставить нельзя) на 32-битах в памть оно физически не влезет. на 64-битах ситуация проще, но тоже будут проблемы. так что нужна база данных. причем шустрая и отзычивая.

но дело даже не в этом. снифферов то ведь нету. даже на энтерпрйз маркете где только сертифицированные оси (никсы, конечно), которые сертифицированны на данном конктетном железе под конкетную задачу -- сниффать траффик конкретной програмой tcpdump куча пробелем. 10% потери пакетов -- это реальность. и это при том, что поддержка энерпрайзных никсов и железа на уровне. но... они же там не боги. вылизали 32 бита. а вот 64 бита все еще сосут.

благо, у ТС не IDS и ему потеря пакетов не страшна. но использовать wincap это безумие однозначно. оно же работает только по большим праздникам. хотя зависит от задачи... потеря пакетов возникает когда загружен ЦП и когда трафик реально валит как дым из трубы.

Здравствуйте, Lloyd, Вы писали:

Z>>Доказательства того, что DDD и anemic несовместимы здесь нет. Есть доказательство совместимости с rich model, при этом, возможна совместимость и с anemic. Основной постулат DDD — максимальное приближение модели данных к естественным сущностям в бизнесе. Я совершенно не понимаю хайпа вокруг этой аббревиатуры.

L>Что-то на этом пункте я завис. А в чем отличие "rich model" от "максимальное приближение модели данных к естественным сущностям в бизнесе"?

рич модель это вариант реализации, а ДДД это вобщем то методология

Здравствуйте, Ikemefula, Вы писали:

L>>Что-то на этом пункте я завис. А в чем отличие "rich model" от "максимальное приближение модели данных к естественным сущностям в бизнесе"?

I>рич модель это вариант реализации, а ДДД это вобщем то методология

С фига ли?! Открой Эванса и убедись, что ДДД — это в том числе и архитектура.

Здравствуйте, Lloyd, Вы писали:

I>>рич модель это вариант реализации, а ДДД это вобщем то методология

L>С фига ли?! Открой Эванса и убедись, что ДДД — это в том числе и архитектура.

Так у Эванса это и написано, что ДДД это сначала методология Про модель он говорит, что нет готового решения, надо пилить, пилить а потом дистилировать.

Будь ДДД архитектурой, достаточно вместо книги накидать пару примеров и сказать что де надо делать вот так.

Здравствуйте, Ikemefula, Вы писали:

L>>С фига ли?! Открой Эванса и убедись, что ДДД — это в том числе и архитектура.

I>Так у Эванса это и написано, что ДДД это сначала методология Про модель он говорит, что нет готового решения, надо пилить, пилить а потом дистилировать.

А ты точно Эванса открывал? У него описанию этого готового решения, которого якобы нет, отводит места больше, чем на методологию.

I>Будь ДДД архитектурой, достаточно вместо книги накидать пару примеров и сказать что де надо делать вот так.

Здравствуйте, Lloyd, Вы писали:

I>>Так у Эванса это и написано, что ДДД это сначала методология Про модель он говорит, что нет готового решения, надо пилить, пилить а потом дистилировать.

L>А ты точно Эванса открывал? У него описанию этого готового решения, которого якобы нет, отводит места больше, чем на методологию.

Главы с 1й до 7й это описание методологии, а не конкретных решений. Да и в последующих главах хватает описания именно методологии.

Естесвтенно, ДДД как методология ни разу не всеохватывающая, как XP и тд.

Здравствуйте, Ikemefula, Вы писали:

L>>А ты точно Эванса открывал? У него описанию этого готового решения, которого якобы нет, отводит места больше, чем на методологию.

I>Главы с 1й до 7й это описание методологии, а не конкретных решений. Да и в последующих главах хватает описания именно методологии.

Зачем вы обманываете? С 4-й по 7-ю главы идет описание архитектуры (7-я пример).

Здравствуйте, Lloyd, Вы писали:

L>>>А ты точно Эванса открывал? У него описанию этого готового решения, которого якобы нет, отводит места больше, чем на методологию.
I>>Главы с 1й до 7й это описание методологии, а не конкретных решений. Да и в последующих главах хватает описания именно методологии.

L>Зачем вы обманываете? С 4-й по 7-ю главы идет описание архитектуры (7-я пример).

Зачем ты обманываешь ?

С 1й по 7ю идет описание подхода к построению архитектуры Разумеется на конкретном примере. Читай внимательно его советы и рекомендации, что делать и что не делать. Это не похоже на архитектуру

Здравствуйте, Ikemefula, Вы писали:

I>>>Главы с 1й до 7й это описание методологии, а не конкретных решений. Да и в последующих главах хватает описания именно методологии.

L>>Зачем вы обманываете? С 4-й по 7-ю главы идет описание архитектуры (7-я пример).

I>Зачем ты обманываешь ?

I>С 1й по 7ю идет описание подхода к построению архитектуры

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

I>Разумеется на конкретном примере.

Не, конкретных решение там нет. Сам Ikemefula об этом писал 2 поста назад, он в теме.

I>Читай внимательно его советы и рекомендации, что делать и что не делать. Это не похоже на архитектуру

У меня для тебя плохие новости.

Здравствуйте, Lloyd, Вы писали:


L>Не можешь прояснить, в чем отличие архитектуры и подхода к построению архитектуры? Решение о размещении бизнес-логики в энтитях — это архитектура, или подход к ней.

Он нигде не говорит о необходимости размещать БЛ в энтитях.


I>>Читай внимательно его советы и рекомендации, что делать и что не делать. Это не похоже на архитектуру

L>У меня для тебя плохие новости.

Т.е. когда он говорит, что модель надо дистилировать, проговаривать, рефакторить денно и нощно — в этом тебе видится конкретная ДДД-архитектура ? Я правильно тебя понял ?

Здравствуйте, Ikemefula, Вы писали:

L>>Не можешь прояснить, в чем отличие архитектуры и подхода к построению архитектуры? Решение о размещении бизнес-логики в энтитях — это архитектура, или подход к ней.

Если ты не заметил, тут был знак вопроса.

I>Он нигде не говорит о необходимости размещать БЛ в энтитях.

Он описал кейсы, когда бизнес-логика попадает в сервисы. Следовательно в остальных кейсах эта логика располагается где-то еще. Единственное место, которое мне приходит в голову — это энтити.
Возможно я ошибаюсь, поправьте меня, если это так и расскажите, где еще может быть расположена логика кроме сервисов и энтитей.

I>>>Читай внимательно его советы и рекомендации, что делать и что не делать. Это не похоже на архитектуру

L>>У меня для тебя плохие новости.

I>Т.е. когда он говорит, что модель надо дистилировать, проговаривать, рефакторить денно и нощно — в этом тебе видится конкретная ДДД-архитектура ? Я правильно тебя понял ?

Простмотри хотя бы заголовки глав с 4-й по 7-ю. Разговоры про "дистилировать, проговаривать, рефакторить" — либо перед этими главами, либо после.