Спасибо, что выделили время на мой конспект. Вопросы хорошие и объемные, но к сожалению, сейчас недостаточно времени, чтобы нормально их проанализировать и ответить в нужной мере. На данный момент у меня пока следующие аргументы:
По поводу 2. В статье упоминалось во время описания мысленного эксперимента «квантовые карты», что волновая функция не описывает никаких конфигураций частиц, при которых вы воспринимали бы карту лежащей лицом верх, когда она лежит лицом вниз, то есть все должно быть согласованно. Если нет возможности предсказать что-то, так это только из-за того, что недостаточно информации, чтобы это сделать. Для 100% предсказания нужно знать текущее состояние всех элементов, которые составляют эту систему, то есть в нашем случае состояние всех элементарных частиц из наблюдаемой вселенной как минимум (если извне, то что мы не наблюдаем не влияет на нашу наблюдаемую часть вселенной). Есть мысленный эксперимент Демон Лапласа — вымышленное разумное существо, способное, восприняв в любой данный момент времени положение и скорость каждой частицы во Вселенной, узнавать её эволюцию как в будущем, так и в прошлом. Лаплас придумал это существо для наглядной демонстрации степени нашей неосведомленности и необходимости в статистическом описании некоторых реальных процессов в окружающем мире.
Из этого вытекает, что не может быть никаких странностей (ваш 3-4 пункты). На все можно найти свою причину.
Да, сразу принимать zip code. В обязанности Address не входит взаимодействие с внешним миром. На уровне слоя приложения получить zip code по api и передать в конструктор (ну или фабричный метод).
Так вы сами ответили на свой вопрос) Луковая что — архитектура, гексагональная что — архитектура) При этом не важно какой язык и так далее. Важно то как взаимодействуют между собой различные части системы.
А пример с CQRS мне кажется притянут за уши. Ну типо можно провести аналогию, что команды только изменяют данные, а запросы только читают данные, но в случае комманд там же тоже можно разделить на иммутабельную часть и мутабельную, где домменный объект это иммутабельная часть, а сама команда (слой приложения) мутабельная. В тоже время запросы могут косвенно (через события) менять состояние, например, если у нас есть статистика просмотров.
Спасибо, что прочитали статью. Но я не соглашусь. Сначала была обресована общая картина, как раз на уровне архитектуры (из википедии Архитектура программного обеспечения — совокупность важнейших решений об организации программной системы). В разделе «Иммутабельность, состояние и побочные эффекты» были обрисованы основные термины и приведен пример на C# для ясности (так как это основной язык на котором работает Хориков). В разделе «Иммутабельная архитектура» как раз была описана именно архитектура (совокупность важнейших решений об организации программной системы). Ну и в разделе «Пример иммутабельной архитектуры» уже конкретный пример.
Тут больше зависит от того, как взаимодействуют между собой Order и Product. Как вы собираетесь передавать объект Product (я предполагаю, что вы имеете ввиду доменный объект, а не DTO), если Order и Product находятся в разных микросервисах. Даже если у нас модульный монолит. Order и Product скорее всего будут находятся в разных модулях. И если один будет напрямую зависит от другого, это как раз и есть нарушение low coupling. Тут или изначально работать с ID. Или внутри каждого модуля/микросервиса делать адаптеры (можно как угодно назвать, я имею ввиду, чтобы были некие сервисы, которые будут запрашивать данные у другого модуля/микросервиса и уже внутри модуля создавать объект Product, но это уже будет не доменный объект, а просто DTO). Такие адаптеры по сути можно назвать кстати anti-corruption layer (https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer).
Но нужно заметить, если проект достаточно простой, то можно не парится и так оставить. Но в тоже время в достаточно простых проектах можно забить и на эти принципи (high cohesion и low coupling).
Спасибо, что выделил время на статью. Автор оригинала приводил примеры в стиле ООП, поэтому, как я понял, он акцентировал внимание именно на полиморфизме. Вы могли заметить, что часто шло перечисление классы/модули/функции/сервисы и так далее. При этом если глянуть в википедию, там следующее: «Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов». Поэтому сам полиморфизм не ограничен рамками ООП.
Не совсем. Первая часть верна. Но второй тест будет содержать теперь —
подготовка — подготовка данных для удаления пользователя
действие — вызов UserController.DeleteUser()
проверка — запрос к БД для проверки успешного удаления
То есть для второго теста у вас уже изначально должен быть готовый зарегистрированный пользователь. Например, тестовая БД заполняется фикстурами (фейковыми данными). И блок подготовки может включать запрос (с помощью репозитория, например) на получения этого фейкового юзера.
Спасибо конечно, что выделили время на статью. Я представления не использую активно. В данной ситуации доверился автору книги. Но это не отменяет ценность материала. Ваша претензия в таком тоне выглядит больше не на замечание, а на самоутверждение, типа «какой я умный». Только перед кем вы решили это показать непонятно.
Я не эксперт в микросервисах. Но из имеющихся знаний могу сказать, что как минимум для независимого развертывания отдельных частей системы, повышения отказоустойчивости всей системы (если выйдет из строя один сервис, остальные будут работать и клиенты могут даже не заметить этого), ну и масштабирование команд разработчиков (я бы посмотрел как над одним монолитом будут работать 50-100+ человек). Но опять же, ни кто не говорит все бросать и переходить на микросервисы. Уже много раз говорили, что они подходят только под большие продукты, которые уже созрели и с ними сложно работать как с монолитами. Если это стартап, то даже не стоит пробовать, тут как раз подойдет модульный монолит.
Ну это ваше мнение. Если бы внимательно читали, то заметили бы, что к этому нужно стремится, а не воспринимать как аксиому (типа только так делать и ни как иначе). В первой части вас никто не обсирал, а просто указали на плохо аргументированную критику. Комментарий во второй части не указывал на то, что там что-то разваливается.
И можете не переживать за то, что комментариев мало. Меня это не волнует. Это мое хобби. Пишу для себя в надежде, что может кого-то еще заинтересует. Если нет, то «ОК».
Спасибо, что выделили время на статью. Это ваше мнение. Спорить не буду. Мне лично было полезно. И знания, которые я получил мне пригодились по работе.
Я не ищу цели переводить и конспектировать все подряд. То, что мне интересно и будет полезно я читаю и иногда конспектирую/перевожу. Я не согласен с вами, что автор оригинала не имеет статуса «авторитетный» в данной области. И ссылки, которые вы скинули — как GoF паттерны касаются агрегатов? Это вообще разные темы.
Благодарю за ваше время, выделенное на мои статьи). Хотя вот уже есть в личке представители «плоской земли», которые возмущаются, что я отравляю разум пользователей)
https://habr.com/ru/post/573788/#comment_23399362
По поводу 2. В статье упоминалось во время описания мысленного эксперимента «квантовые карты», что волновая функция не описывает никаких конфигураций частиц, при которых вы воспринимали бы карту лежащей лицом верх, когда она лежит лицом вниз, то есть все должно быть согласованно. Если нет возможности предсказать что-то, так это только из-за того, что недостаточно информации, чтобы это сделать. Для 100% предсказания нужно знать текущее состояние всех элементов, которые составляют эту систему, то есть в нашем случае состояние всех элементарных частиц из наблюдаемой вселенной как минимум (если извне, то что мы не наблюдаем не влияет на нашу наблюдаемую часть вселенной). Есть мысленный эксперимент Демон Лапласа — вымышленное разумное существо, способное, восприняв в любой данный момент времени положение и скорость каждой частицы во Вселенной, узнавать её эволюцию как в будущем, так и в прошлом. Лаплас придумал это существо для наглядной демонстрации степени нашей неосведомленности и необходимости в статистическом описании некоторых реальных процессов в окружающем мире.
Из этого вытекает, что не может быть никаких странностей (ваш 3-4 пункты). На все можно найти свою причину.
А пример с CQRS мне кажется притянут за уши. Ну типо можно провести аналогию, что команды только изменяют данные, а запросы только читают данные, но в случае комманд там же тоже можно разделить на иммутабельную часть и мутабельную, где домменный объект это иммутабельная часть, а сама команда (слой приложения) мутабельная. В тоже время запросы могут косвенно (через события) менять состояние, например, если у нас есть статистика просмотров.
Но нужно заметить, если проект достаточно простой, то можно не парится и так оставить. Но в тоже время в достаточно простых проектах можно забить и на эти принципи (high cohesion и low coupling).
подготовка — подготовка данных для удаления пользователя
действие — вызов UserController.DeleteUser()
проверка — запрос к БД для проверки успешного удаления
То есть для второго теста у вас уже изначально должен быть готовый зарегистрированный пользователь. Например, тестовая БД заполняется фикстурами (фейковыми данными). И блок подготовки может включать запрос (с помощью репозитория, например) на получения этого фейкового юзера.
И можете не переживать за то, что комментариев мало. Меня это не волнует. Это мое хобби. Пишу для себя в надежде, что может кого-то еще заинтересует. Если нет, то «ОК».