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

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

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

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

Если ты незаметил, это ответ на твой вопрос.

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

Он показывает рассуждения о том как нужно строить архитектуру. А если в конкретном варианте это попало в сервисы — дело десятое.

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

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

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

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

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

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

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

I>Если ты незаметил, это ответ на твой вопрос.

Нет, это не ответ на вопрос "в чем отличие архитектуры и подхода к построению архитектуры".

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

I>Он показывает рассуждения о том как нужно строить архитектуру. А если в конкретном варианте это попало в сервисы — дело десятое.

Он описывает, какого рода операции попадают в сервисы. Ответ на вопрос о том, куда попадают остальные операции, лежит на поверхности.

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

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

I>Похоже, ты читал только заголовки

Похоже, ты знаком с содержанием только по слухам, раз не заметил полкниги.

I>Под рукой у меня нет книги, а дома есть книга но нет компа, что бы процитировать. Как быть ?

rutracker.org в помощь.

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

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

I>>Если ты незаметил, это ответ на твой вопрос.

L>Нет, это не ответ на вопрос "в чем отличие архитектуры и подхода к построению архитектуры".

Разница в рекомендациях которые дает автор. Если Эванс говорит "размещать БЛ надо в сервисах(энтитях, контроллере и тд)" то конечно он описывает архитектуру. А если вместо этого говорит о том, как прийти к конкретной модели, как модель влияет на дизайн, талдычит про язык, рефакторинг и тд, то речь о подходе.

I>>Он показывает рассуждения о том как нужно строить архитектуру. А если в конкретном варианте это попало в сервисы — дело десятое.
L>Он описывает, какого рода операции попадают в сервисы. Ответ на вопрос о том, куда попадают остальные операции, лежит на поверхности.

Он говорит про подход

I>>Похоже, ты читал только заголовки
L>Похоже, ты знаком с содержанием только по слухам, раз не заметил полкниги.

Важные вещи я читаю дважды а то и трижды Сам Эванс не считает ДДД методологией и его можно понять, в ДДД нет ничего про планирование и управление. Тем не менее это методология разработки архитектуры. Т.е. методология как подход, а не аналог таких вещей как XP, Scrum и тд.

Теперь вопрос, раз ты читал эту книгу, можно ли архитектуру определить как "a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. " ?

Хочу получить простой ответ, вроде да — можно, нет — нельзя.

I>>Под рукой у меня нет книги, а дома есть книга но нет компа, что бы процитировать. Как быть ?

L>rutracker.org в помощь.

дай ссылку на всю книгу, у меня нет доступа к этому ресурсу.

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

L>>Нет, это не ответ на вопрос "в чем отличие архитектуры и подхода к построению архитектуры".

I>Разница в рекомендациях которые дает автор. Если Эванс говорит "размещать БЛ надо в сервисах(энтитях, контроллере и тд)" то конечно он описывает архитектуру. А если вместо этого говорит о том, как прийти к конкретной модели, как модель влияет на дизайн, талдычит про язык, рефакторинг и тд, то речь о подходе.

I>>>Он показывает рассуждения о том как нужно строить архитектуру. А если в конкретном варианте это попало в сервисы — дело десятое.
L>>Он описывает, какого рода операции попадают в сервисы. Ответ на вопрос о том, куда попадают остальные операции, лежит на поверхности.

I>Он говорит про подход

Вы меня прям в рекурсию загоняете. Двумя строчками было "размещать БЛ надо в сервисах" — это архитектура, теперь то же самое — подход.
Хм, надеюсь, что дело все-таки в лыжах, а не во мне.

I>>>Похоже, ты читал только заголовки
L>>Похоже, ты знаком с содержанием только по слухам, раз не заметил полкниги.

I>Важные вещи я читаю дважды а то и трижды Сам Эванс не считает ДДД методологией и его можно понять, в ДДД нет ничего про планирование и управление. Тем не менее это методология разработки архитектуры. Т.е. методология как подход, а не аналог таких вещей как XP, Scrum и тд.

Зачем ты это раз за разом повторяешь? Я где-то оспаривал это утверждение? Вроде нет.
Мой поинт лишь в том, что это не только методология, но и вполне себе архитектура, одним из пунктов которой является rich-ность модели.

I>Теперь вопрос, раз ты читал эту книгу, можно ли архитектуру определить как "a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. " ?

I>Хочу получить простой ответ, вроде да — можно, нет — нельзя.

Извини, но это out-of-scope того, что обсуждается. Если хочешь, создавай отдельную тему, но участвовать в ней я не буду.

L>>rutracker.org в помощь.

I>дай ссылку на всю книгу, у меня нет доступа к этому ресурсу.

Она и так гуглится, без торрента.

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

L>Вы меня прям в рекурсию загоняете. Двумя строчками было "размещать БЛ надо в сервисах" — это архитектура, теперь то же самое — подход.

А дай ка ссылку, где я писал вроде "Эванс пишет 'размещать БЛ надо в сервисах'" ?

I>>Важные вещи я читаю дважды а то и трижды Сам Эванс не считает ДДД методологией и его можно понять, в ДДД нет ничего про планирование и управление. Тем не менее это методология разработки архитектуры. Т.е. методология как подход, а не аналог таких вещей как XP, Scrum и тд.

L>Зачем ты это раз за разом повторяешь? Я где-то оспаривал это утверждение? Вроде нет.
L>Мой поинт лишь в том, что это не только методология, но и вполне себе архитектура, одним из пунктов которой является rich-ность модели.

Астролябия, как модель звездного неба, это рич или анемик ? Эванс говорит, что если нарисовалась модель, то надо сделать её как следует и для этого выдает кучу рекомендаций, приоритеторв и тд и тд.

I>>Теперь вопрос, раз ты читал эту книгу, можно ли архитектуру определить как "a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. " ?

I>>Хочу получить простой ответ, вроде да — можно, нет — нельзя.

L>Извини, но это out-of-scope того, что обсуждается. Если хочешь, создавай отдельную тему, но участвовать в ней я не буду.

Это слова Эванса непосредственно относящиеся к его книге и ДДД. Фраза однозначно разрешает вопрос архитектура ДДД или нет.

I>>дай ссылку на всю книгу, у меня нет доступа к этому ресурсу.

L>Она и так гуглится, без торрента.

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

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

L>>Вы меня прям в рекурсию загоняете. Двумя строчками было "размещать БЛ надо в сервисах" — это архитектура, теперь то же самое — подход.

I>А дай ка ссылку, где я писал вроде "Эванс пишет 'размещать БЛ надо в сервисах'" ?

rsdn.ru/forum/philosophy/4434550.1.aspx

L>>Зачем ты это раз за разом повторяешь? Я где-то оспаривал это утверждение? Вроде нет.
L>>Мой поинт лишь в том, что это не только методология, но и вполне себе архитектура, одним из пунктов которой является rich-ность модели.

I>Астролябия, как модель звездного неба, это рич или анемик ? Эванс говорит, что если нарисовалась модель, то надо сделать её как следует и для этого выдает кучу рекомендаций, приоритеторв и тд и тд.

Зачем вы постоянно уходите в сторону? Вам же приводят вполне конкретные цитаты из главы про сервисы, а вы постоянно уплываете куда-то в философию.

L>>Извини, но это out-of-scope того, что обсуждается. Если хочешь, создавай отдельную тему, но участвовать в ней я не буду.

I>Это слова Эванса непосредственно относящиеся к его книге и ДДД. Фраза однозначно разрешает вопрос архитектура ДДД или нет.

Нет, не разрешает. Если я скажу я — пионер, это не будет значить, что я — не Петя Васечкин.

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

VD>>Позволь полюбопытствовать, а "нормальная архитектура" и ООП — это одно и то же?

VS>Вопрос с подвохом

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

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

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

Говногод он по любому говнокод. Он парадигм он не зависит.

VS>Номер раз — процедурщина.

О, как? А ничего, что самые объемные и не простые программные продукты вроде Винды и Линукса в основном написаны на С в самоно, то ни на есть процедурном стиле?

VS>Этого добра так много, что номер два (нездоровое увлечение фп) на ее фоне почти незаметен. Немного фп внутри класса — ок, упрощает рутинные операции, но когда пытаются строить на этом архитектуру — это даже не смешно.

А я вот знаю людей пишуших на Хаскеле и считающих, что этот язык позволяет им сделать архитектуру их ПО очень красивой и правильной. Что они делают не так?

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

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

Так что не надо делать из ООП очередную панацею. То что кто-то освоил в основном только ООП не означает, что за пределами ООП нет жизни.

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

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

L>>>Вы меня прям в рекурсию загоняете. Двумя строчками было "размещать БЛ надо в сервисах" — это архитектура, теперь то же самое — подход.

I>>А дай ка ссылку, где я писал вроде "Эванс пишет 'размещать БЛ надо в сервисах'" ?

L>rsdn.ru/forum/philosophy/4434550.1.aspx

Стало быть для тебя "Если" == "" Как тебе что либо объяснить, я даже не знаю тперь.

L>>>Извини, но это out-of-scope того, что обсуждается. Если хочешь, создавай отдельную тему, но участвовать в ней я не буду.
I>>Это слова Эванса непосредственно относящиеся к его книге и ДДД. Фраза однозначно разрешает вопрос архитектура ДДД или нет.

L>Нет, не разрешает. Если я скажу я — пионер, это не будет значить, что я — не Петя Васечкин.

way of thinking никак не может быть архитектурой

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

L>>>>Вы меня прям в рекурсию загоняете. Двумя строчками было "размещать БЛ надо в сервисах" — это архитектура, теперь то же самое — подход.

I>>>А дай ка ссылку, где я писал вроде "Эванс пишет 'размещать БЛ надо в сервисах'" ?

L>>rsdn.ru/forum/philosophy/4434550.1.aspx

I>Стало быть для тебя "Если" == "" Как тебе что либо объяснить, я даже не знаю тперь.

Если Эванс говорит "размещать БЛ надо в сервисах(энтитях, контроллере и тд)" то конечно он описывает архитектуру.

Утверждение "Эванс говорит "размещать БЛ надо в сервисах(энтитях, контроллере и тд)"" — верно, я приводил цитату из раздела про сервисы.
Подставляя true в процитированное "Если", получаем, что Эванс описывает архитектуру.

Между тем, тут

L>Он описывает, какого рода операции попадают в сервисы. Ответ на вопрос о том, куда попадают остальные операции, лежит на поверхности.

Он говорит про подход

ты утверждаешь, что это не архитектура, а подход.

Ты уж как-нибудь определись уже.

L>>>>Извини, но это out-of-scope того, что обсуждается. Если хочешь, создавай отдельную тему, но участвовать в ней я не буду.
I>>>Это слова Эванса непосредственно относящиеся к его книге и ДДД. Фраза однозначно разрешает вопрос архитектура ДДД или нет.

L>>Нет, не разрешает. Если я скажу я — пионер, это не будет значить, что я — не Петя Васечкин.

I>way of thinking никак не может быть архитектурой

Это просто праздник какой-то, ты даже элементарными логическими операциями оперировать не можешь.
"way of thinking" может и не может быть архитектурой (хрен с ним), но ddd ею не только может быть, но и является.

На всякий случай: "A is B" — это не то же самое, что и "A == B". А из того, что "A is B" и "A is С" не следует никакой связи между B и C.

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

М>вот я и думаю -- а что мне дадут плюсы, если их выучить? питон мне дал высокую продуктивность и учить его не пришлось (так, полистал книжку на выходных), java script дала высокую портабельность (работает _везде_, включая мобилки и опять без затрат на обучение), чистый си дает производительность, но нам нем пишутся только самые низкоуровневые компоненты, а обвязка -- жаба, питон, руби или скала.

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

Главная фича плюсов — их фичи можно использовать избирательно. Поэтому например я могу писать на С++ для 8-битников, используя наследование и шаблоны и не используя динамическую память, stl и исключения. По сравнению с чистыми сями получается весьма неплохо.

Главный минус питона и яваскрипта для меня — отсутствие компиляции. В отсутствии хорошего покрытия тестами приятно иметь за спиной компилятор. Но например для билд-скриптов питон самое оно. Они довольно компактные, результат виден и проверяем сразу.

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

E>Главный минус питона и яваскрипта для меня — отсутствие компиляции. В отсутствии хорошего покрытия тестами приятно иметь за спиной компилятор. Но например для билд-скриптов питон самое оно. Они довольно компактные, результат виден и проверяем сразу.

для питона компиляторы есть. очень помогают обнаруживать баги

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

L>Я хотел бы спросить. Вот поступает задача. У меня как у фрилансера это часто, на месяц неделю итд.
L>Ну я стараюсь разбить ее на классы, объекты сначала. Но эта внутренняя красивость не дает нужного результата в релизе. Скажите как вы делаете задание с нуля. Главное ведь чтоб работало? А это "эстетствующее" никак с ним не вяжется. Кому интересно что там внутри.

Лично мне в последние лет пять редко приходится делать что-то "с нуля", обычно речь идёт о том, чтобы "залезть внутрь и доработать под капотом не выключая двигатель"

И вот чему учит первый проект на 50M строк -- кодить просто, кодить мало, кодить только то, что нужно. Самый лучший дизайн у той программы, которая никогда не была написана, потому что удалось доказать, что писать её не надо. Именно это -- идеал. Если вы нарисовали иерархию классов и видите, что один можно выкинуть -- сделайте это. Если можно выкинуть все классы и написать на C -- сделайте это. Язык С лучше для чтения чем С++, в C вы всегда знаете, что у вас сегодня утром делает операция "+". Если можно вообще ничего не кодить а просто прикутить готовую библиотеку -- сделайте это. Из любой точки А в любую Б может и должна вести прямая. Я сам этого не понимал ещё несколько лет назад. Мы программисты, и способны получать удовольствие от разработки как таковой, а значит часто бываем увлечены процессом, не результатом. Это надо про себя понимать и в себе контролировать. Постоянно держите перед глазами результат и прокладывайте кратчайший, простейший маршрут.

Но не вздумайте сделать проще чем надо.

Во-первых есть решения и инструменты которые кажутся простыми, таковыми не являясь. Я не буду подробно останавливаться -- копипаст, макросы (в обоих смыслах), goto, volatile в многопоточном окружении, продолжайте сами. Самое главное, когда речь идёт о простоте -- не надо экономить свои усилия к написанию кода. Вместо этого вы экономите чужие усилия к его прочтению и переиспользованию. И этим сберегаются ваши усилия.
Во-вторых есть минутные слабости, которые кажутся незначительными. Завести в функции статическую переменную, ведь она никогда не будет использована в многопоточном окружении. А вот в эту функцию на три экрана я всегда могу добавить ещё одно условие в case, всего двадцать строк. А вот здесь я один разок нажму ctrl-v и никто не заметит. Бейте себя по рукам линейкой за каждую такую минутную слабость.

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

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

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

E>>Главный минус питона и яваскрипта для меня — отсутствие компиляции. В отсутствии хорошего покрытия тестами приятно иметь за спиной компилятор. Но например для билд-скриптов питон самое оно. Они довольно компактные, результат виден и проверяем сразу.

М>для питона компиляторы есть. очень помогают обнаруживать баги

Если ты про пилинт, то помогает, но никакого сравнения с компилятором той же явы или с++ не выдерживает.

А с учетом того, что язык динамический, что-то лучшее для него написать сложно

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

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

T>Но не вздумайте сделать проще чем надо.
+100500

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

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

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

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

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

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

E>>>Главный минус питона и яваскрипта для меня — отсутствие компиляции. В отсутствии хорошего покрытия тестами приятно иметь за спиной компилятор. Но например для билд-скриптов питон самое оно. Они довольно компактные, результат виден и проверяем сразу.

М>>для питона компиляторы есть. очень помогают обнаруживать баги

E>Если ты про пилинт, то помогает, но никакого сравнения с компилятором той же явы или с++ не выдерживает.
я цейтон использую. правда, он тащит за собой все питоновские библиотеки. т.е. на целевой машине питон все-таки должен быть. но компиляция вполне нормальная. самый главный минус -- не все питоновские фичи поддерживаются. [a*3 for a in range(100) if a % 3] -- не поддерживается. абыдно.

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

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

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

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

Корабли строят не сразу. Что бы построить через 50 лет корабль, который обгонит другие, его потребуется строить все 50 лет, ломая и переделывая, учитывая опыт. Если мы сегодня не будем делать то что нужно будет через 50 лет, то через 50 лет ничего хорошего не получится.
Кроме этого, мы сегодня пишем софт для сегодняшних задач, а не для того корабля, который через 50 лет то ли полетит то ли его не сделают что бы полететь через 100 лет быстрее. Ситуация может быть прямо противоположной. Если мы не сделаем сегодня плохо, то завтра конкуренты сделают еще хуже и снимут пенки.

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

М>я цейтон использую.

А как он правильно называется? Что-то не получается нагуглить

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

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

А как вообще так можно сделать? Разве можно написать код, работающий и на 3.xx и на 2.xx? Все библиотеки, которые я юзаю, имеют отдельные версии для 2-го и 3-го питонов

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

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

L>>>>>Вы меня прям в рекурсию загоняете. Двумя строчками было "размещать БЛ надо в сервисах" — это архитектура, теперь то же самое — подход.

I>>>>А дай ка ссылку, где я писал вроде "Эванс пишет 'размещать БЛ надо в сервисах'" ?

L>>>rsdn.ru/forum/philosophy/4434550.1.aspx

I>>Стало быть для тебя "Если" == "" Как тебе что либо объяснить, я даже не знаю тперь.

L>

L>Если Эванс говорит "размещать БЛ надо в сервисах(энтитях, контроллере и тд)" то конечно он описывает архитектуру.

L>Утверждение "Эванс говорит "размещать БЛ надо в сервисах(энтитях, контроллере и тд)"" — верно, я приводил цитату из раздела про сервисы.
L>Подставляя true в процитированное "Если", получаем, что Эванс описывает архитектуру.

L>Между тем, тут
L>

L>>Он описывает, какого рода операции попадают в сервисы. Ответ на вопрос о том, куда попадают остальные операции, лежит на поверхности.

L>Он говорит про подход

L>ты утверждаешь, что это не архитектура, а подход.

L>Ты уж как-нибудь определись уже.

L>>>>>Извини, но это out-of-scope того, что обсуждается. Если хочешь, создавай отдельную тему, но участвовать в ней я не буду.
I>>>>Это слова Эванса непосредственно относящиеся к его книге и ДДД. Фраза однозначно разрешает вопрос архитектура ДДД или нет.

L>>>Нет, не разрешает. Если я скажу я — пионер, это не будет значить, что я — не Петя Васечкин.

I>>way of thinking никак не может быть архитектурой

L>Это просто праздник какой-то, ты даже элементарными логическими операциями оперировать не можешь.
L>"way of thinking" может и не может быть архитектурой (хрен с ним), но ddd ею не только может быть, но и является.

L>На всякий случай: "A is B" — это не то же самое, что и "A == B". А из того, что "A is B" и "A is С" не следует никакой связи между B и C.

L>Утверждение "Эванс говорит "размещать БЛ надо в сервисах(энтитях, контроллере и тд)"" — верно, я приводил цитату из раздела про сервисы.

Эванс лишь советует.
Домен это не только энтити с методами. а так же сервисы и инфраструктура.
Ты как-то узко мыслишь.
Сам Эванс всю книгу говорит быть прагматичнее.
Но ты почему-то воспринимаешь всё буквально.