С ентити не особо понял вашу мысль. Ядро у нас это доменные интерфейсы, сигнатуры его методов в хорошей архитектуре всегда зависят от сущностей и более ни от чего. Сущности же не зависят ни от чего вообще. Пользуясь вашей аналогией, если в вашей системе появится сущность бигмака - она появится и в ядре (надеюсь я верно уловил аналогию). В фудтехе, раз уж мы про еду, это обычно блюдо, наследуемое от товара, который в свою очередь наследует какую-нить "позицию", если там появдяется например "услуга", то у нее появятся свои специфические бизнес-кейсы и она так же унаследует позицию, чтобы посредством общих кейсов для позиции например оказаться в чеке.
Насчет ультимативности - мне например не нравится такое деление. И такая терминология. И тут я отдаю себе отчет что это вкусовщина. Мне как раз и не нравится что нет допуска вкусовщине в рамках фундаментальный принципов. Помните VIPER? Был еще шуточный репозиторий на гитхабе с его перефразом. История его зашла в тупик довольно быстро. Сам по себе подход ок. Но это конкретная имплементация некоторых принципов для конкретного случая. Мир куда разнообразнее и строить архитектуру и инфраструктуру проекта надо с оглядкой на совсем не технические факторы. Тут даже дело не в бигтехе, точнее не совсем в нем. Супераппом станет дай бог 1% приложений, 99% не дорастут даже до объема в 300K строк. Из них еще меньше дорастет до своего объема не за счет богатого домена, а не бесконечного дублирования презентационных фич с вариациями. Опять же из-за плохой структурированности GUI. Вследствие отсутствия ресурсов на подготовку собственного юай-кита и плохой продуктовой проработки. Видите: одно за другое, одно за другое.
Тут и упомянутый плохой архитектурный контроль вылезет. И приходим мы на проект чаще всего не на начальной стадии, а когда эти детские болезни развиваются в патологию. То есть особенности принятых решений вносят существенное время в реализацию не только новых фич, но и в стабилизацию старых. И тут нельзя просто взять схему и все пересобрать. Берется что есть, это "что есть" рефакторится по чистым фундаментальным вещам. И уже после этого этапа можно работать с архитектурой. Но. Это. Все. Очень. Дорого. И тут я за 20 лет практики рецепта не придумал. Если вы думаете что ваша ультимативность поможет проекту лет через пять, уже без вас, не упасть в эту яму - вы заблуждаетесь. Максимум - его не успеют слишком уж изуродовать до тех пор пока он не перейдет под контроль к хорошему лиду.
Насчет модулей примерно те же возражения - я видел как вы выражаетесь "монолиты" которые более приспособлены для разделения на модули нежели изначально многомодульные приложения которым имеет смысл такими быть. Хотя "монолиты" вовсе из другой оперы. Сервисы в бекенде это по своей сути отдельные приложения, выполняющие свои узконаправленные функции, а не какие-то там библиотеки, которые компонуются в одно. В общем случае монолитный сервис бека может быть так же попилен на модули. И собираться в монолит, который фиг попилишь на отдельные. Так что, опять же, терминологическая путаница нас тут поджидает. Но в целом хорошо что мы сходимся в целях модульности.
А претензий у меня на самом деле нет. У вас есть свое мнение и какое-то видение. У меня есть свое. Я тут ради подискутировать на досуге.
ага-ага, и главное при этом пишется всегда красиво про то что "нужна не энциклопедия", с которой мы спросим как с большого энциклопедического словаря
я проводил собеседований больше чем их проходил и неподсознательно знаю что если ты человека заслушался - надо его попробовать, а вот если не заслушался, то будь он хоть трижды бестящим в "базе", то в автономе он сдуется почти сразу
первое при этом может не сработать, но второе сработает всегда, однако логика собесов на 99% за энциклопедию
а еще мы ж все помним что навык прохождения технических собеседований это асболютно отдельная дисциплина, отличная от навыков нужных в работе и не все готовы ее дрессировать в ущерб работе, слава богу, нафига мне заряженные на собесовские задачки роботы, не умеющие думать и искать
так что пока кто-то стартельно упражняется в дисциплине "мне мало было экзаменов в универе, теперь я принес эту срань в кадровую политику", вменяемые собеседующие щупают релевантность опыта конкретной позиции, птушта есть ключевые навыки, а есть те которые мы сами приобретали в процессе нового проекта с чистого листа и мы про это помним
Есть правила клин, есть правила солид, еще теперь эти правила которые те же яйца только сбоку. И в которых, кстати, упущена судьба ентити. Про направление есть, а про ентити нет - а ведь это важная деталь об которую и ломаются, собственно, эти направления.
Ну то есть ты говоришь человеку что интерфейс репозитория это доменная сущность, и он отдает доменный же ентити, которые не могут иметь зависимостей от аннотаций его ORM/Serializer, а он прикидывает сколько ему делать конвертеров для DTO/DBO и не делает буквально только для этого. А потом вместо него приходит еще один и начинает использовать имеющуюся зависимость и в хвост и в гриву, хотя для одного автора такой подход был допустимым. И будет допустимым в проекте с небольшим или однообразным доменом и жесткой конвенцией. Но у тебя текучка, слабый архитектурный контроль и все накрывается одним местом.
А так конечно неплохой пример имплементации клина для внутренних конвенций конкретного проекта. Несколько царапают глаз ультимативные заявления, потому что можно эту схему переколбасить десятком способов не нарушая ни самого клина, ни заявленных дополнительных правил. Есть, например, чудесные комбайны которые делают BLoC, причем не как ui-стейт-менеджмент, а вполне себе подходящим для доменного уровня образом. Да и еще много чего есть.
Ну и на вкусненькое мое любимое - разбиение на модули не предназначено для ускорения сборки проекта. То есть это не значит что оно не может ускорить. Но оно не для этого. В реальной жизни почти всегда накладных расходов на градл наваливается столько, что выигрыш от распараллеливания сборки модулей съедает весь профит. Максимум
Вообще эта легенда родилась у незатейливых слушателей на конференциях, где докладчики из бигтеха, вынужденные пользоваться разбиением в инфраструктурных целях, сталкиваются с тем что градл у них немножечко умирает от тысяч модулей. И они начинают уже эту проблему решать. А после гордо несут ее на конференцию, неосмотрительно назвав доклад "как я ускорил сборку проекта разбив его на модули", хотя это, мягко говоря, не совсем так. Сначала мы родили проблему разбиением, потом переразбили, частично решив проблему. За кадром как обычно самое главное - жирнющие монорепы на всю линейку продуктов, необходимость структурирования кода для нескольких автономных команд в десятки человек и прочие инфраструктурные фокусы. Не у всех, но как правило. Обычно говорят о том как правильно разбивать, а не о том зачем.
Сколько языков вы знаете, поддерживающих одновременно и сильную и статическую? Я вот всего два. И только один практикую. В упомянутой жабе - типизация статическая, но слабая. Однако автобрекетинг и прочее неявное приведение не делает ее менее пригодной для промышленного применения чем сильные но динамические пхп и жс, а выведения у нее появились для тех кто не залип на мобайле (>1.8).
Так вот собственно вопрос. Что именно вы все-таки будете защищать до последнего? Явные типы в компайл-тайме или отсутствие неявных приведений? Потому что оба двое - редкое явление.
С ентити не особо понял вашу мысль. Ядро у нас это доменные интерфейсы, сигнатуры его методов в хорошей архитектуре всегда зависят от сущностей и более ни от чего. Сущности же не зависят ни от чего вообще. Пользуясь вашей аналогией, если в вашей системе появится сущность бигмака - она появится и в ядре (надеюсь я верно уловил аналогию). В фудтехе, раз уж мы про еду, это обычно блюдо, наследуемое от товара, который в свою очередь наследует какую-нить "позицию", если там появдяется например "услуга", то у нее появятся свои специфические бизнес-кейсы и она так же унаследует позицию, чтобы посредством общих кейсов для позиции например оказаться в чеке.
Насчет ультимативности - мне например не нравится такое деление. И такая терминология. И тут я отдаю себе отчет что это вкусовщина. Мне как раз и не нравится что нет допуска вкусовщине в рамках фундаментальный принципов. Помните VIPER? Был еще шуточный репозиторий на гитхабе с его перефразом. История его зашла в тупик довольно быстро. Сам по себе подход ок. Но это конкретная имплементация некоторых принципов для конкретного случая. Мир куда разнообразнее и строить архитектуру и инфраструктуру проекта надо с оглядкой на совсем не технические факторы. Тут даже дело не в бигтехе, точнее не совсем в нем. Супераппом станет дай бог 1% приложений, 99% не дорастут даже до объема в 300K строк. Из них еще меньше дорастет до своего объема не за счет богатого домена, а не бесконечного дублирования презентационных фич с вариациями. Опять же из-за плохой структурированности GUI. Вследствие отсутствия ресурсов на подготовку собственного юай-кита и плохой продуктовой проработки. Видите: одно за другое, одно за другое.
Тут и упомянутый плохой архитектурный контроль вылезет. И приходим мы на проект чаще всего не на начальной стадии, а когда эти детские болезни развиваются в патологию. То есть особенности принятых решений вносят существенное время в реализацию не только новых фич, но и в стабилизацию старых. И тут нельзя просто взять схему и все пересобрать. Берется что есть, это "что есть" рефакторится по чистым фундаментальным вещам. И уже после этого этапа можно работать с архитектурой. Но. Это. Все. Очень. Дорого. И тут я за 20 лет практики рецепта не придумал. Если вы думаете что ваша ультимативность поможет проекту лет через пять, уже без вас, не упасть в эту яму - вы заблуждаетесь. Максимум - его не успеют слишком уж изуродовать до тех пор пока он не перейдет под контроль к хорошему лиду.
Насчет модулей примерно те же возражения - я видел как вы выражаетесь "монолиты" которые более приспособлены для разделения на модули нежели изначально многомодульные приложения которым имеет смысл такими быть. Хотя "монолиты" вовсе из другой оперы. Сервисы в бекенде это по своей сути отдельные приложения, выполняющие свои узконаправленные функции, а не какие-то там библиотеки, которые компонуются в одно. В общем случае монолитный сервис бека может быть так же попилен на модули. И собираться в монолит, который фиг попилишь на отдельные. Так что, опять же, терминологическая путаница нас тут поджидает. Но в целом хорошо что мы сходимся в целях модульности.
А претензий у меня на самом деле нет. У вас есть свое мнение и какое-то видение. У меня есть свое. Я тут ради подискутировать на досуге.
А можно просто bloc взять, как любой мобильный разработчик
ага-ага, и главное при этом пишется всегда красиво про то что "нужна не энциклопедия", с которой мы спросим как с большого энциклопедического словаря
я проводил собеседований больше чем их проходил и неподсознательно знаю что если ты человека заслушался - надо его попробовать, а вот если не заслушался, то будь он хоть трижды бестящим в "базе", то в автономе он сдуется почти сразу
первое при этом может не сработать, но второе сработает всегда, однако логика собесов на 99% за энциклопедию
а еще мы ж все помним что навык прохождения технических собеседований это асболютно отдельная дисциплина, отличная от навыков нужных в работе и не все готовы ее дрессировать в ущерб работе, слава богу, нафига мне заряженные на собесовские задачки роботы, не умеющие думать и искать
так что пока кто-то стартельно упражняется в дисциплине "мне мало было экзаменов в универе, теперь я принес эту срань в кадровую политику", вменяемые собеседующие щупают релевантность опыта конкретной позиции, птушта есть ключевые навыки, а есть те которые мы сами приобретали в процессе нового проекта с чистого листа и мы про это помним
Есть правила клин, есть правила солид, еще теперь эти правила которые те же яйца только сбоку. И в которых, кстати, упущена судьба ентити. Про направление есть, а про ентити нет - а ведь это важная деталь об которую и ломаются, собственно, эти направления.
Ну то есть ты говоришь человеку что интерфейс репозитория это доменная сущность, и он отдает доменный же ентити, которые не могут иметь зависимостей от аннотаций его ORM/Serializer, а он прикидывает сколько ему делать конвертеров для DTO/DBO и не делает буквально только для этого. А потом вместо него приходит еще один и начинает использовать имеющуюся зависимость и в хвост и в гриву, хотя для одного автора такой подход был допустимым. И будет допустимым в проекте с небольшим или однообразным доменом и жесткой конвенцией. Но у тебя текучка, слабый архитектурный контроль и все накрывается одним местом.
А так конечно неплохой пример имплементации клина для внутренних конвенций конкретного проекта. Несколько царапают глаз ультимативные заявления, потому что можно эту схему переколбасить десятком способов не нарушая ни самого клина, ни заявленных дополнительных правил. Есть, например, чудесные комбайны которые делают BLoC, причем не как ui-стейт-менеджмент, а вполне себе подходящим для доменного уровня образом. Да и еще много чего есть.
Ну и на вкусненькое мое любимое - разбиение на модули не предназначено для ускорения сборки проекта. То есть это не значит что оно не может ускорить. Но оно не для этого. В реальной жизни почти всегда накладных расходов на градл наваливается столько, что выигрыш от распараллеливания сборки модулей съедает весь профит. Максимум
Вообще эта легенда родилась у незатейливых слушателей на конференциях, где докладчики из бигтеха, вынужденные пользоваться разбиением в инфраструктурных целях, сталкиваются с тем что градл у них немножечко умирает от тысяч модулей. И они начинают уже эту проблему решать. А после гордо несут ее на конференцию, неосмотрительно назвав доклад "как я ускорил сборку проекта разбив его на модули", хотя это, мягко говоря, не совсем так. Сначала мы родили проблему разбиением, потом переразбили, частично решив проблему. За кадром как обычно самое главное - жирнющие монорепы на всю линейку продуктов, необходимость структурирования кода для нескольких автономных команд в десятки человек и прочие инфраструктурные фокусы. Не у всех, но как правило. Обычно говорят о том как правильно разбивать, а не о том зачем.
Сколько языков вы знаете, поддерживающих одновременно и сильную и статическую? Я вот всего два. И только один практикую. В упомянутой жабе - типизация статическая, но слабая. Однако автобрекетинг и прочее неявное приведение не делает ее менее пригодной для промышленного применения чем сильные но динамические пхп и жс, а выведения у нее появились для тех кто не залип на мобайле (>1.8).
Так вот собственно вопрос. Что именно вы все-таки будете защищать до последнего? Явные типы в компайл-тайме или отсутствие неявных приведений? Потому что оба двое - редкое явление.