Оригинал: Miss Sister Taste (идентификатор публичной учетной записи WeChat: xjjdog), добро пожаловать, пожалуйста, сохраните источник для перепечатки.
Персонажи Niu B давно устали от смешения китайского и английского, они пошли еще дальше и использовали китайские и английские аббревиатуры, чтобы уменьшить размерность до обычных людей. Еще более мощный, создавайте новые термины и популяризируйте их.
Есть несколько технологий, которые я презираю и ненавижу всем сердцем, но каждый раз добавляю их в техническое решение и придаю им достаточное значение. Потому что они играют важную концептуальную направляющую роль в успехе программы.
Это промежуточная стадия, низкий уровень кода и DDD. Технологии в этих трех разных областях несут одну и ту же ответственность, то есть дурачиться до смерти. Эти три слова великолепны. У них есть одна общая черта. Их легко убедить нетехнических, но принимающих решения людей, а затем распространить их. Они очень ориентированы на маркетинг и являются фаворитами профессиональных менеджеров и технических директоров. Это также фаворит консалтинговых фирм.
Некоторые из этих вещей могут обмануть большие компании, некоторые могут обмануть небольшие компании, и в любом случае никто не хочет убегать.
Но если рак может принести нам пользу, конечно, мы должны принять его. Не будь таким жестким.
Когда дует демонический ветер, мы должны принять его и делать то, что хотим, а не закрывать окно! Почему у некоторых людей высокая заработная плата, а некоторые люди быстро растут! Некоторые люди становятся мастерами! Подумайте фундаментально, почему.
Концепции могут сублимировать системы
вы знаете? Чем выше положение, тем легче любить иллюзорные вещи. Возьмем, к примеру, древних императоров: многие ожидали встречи с богами, но были обмануты алхимиками. Даже если вы знаете в конце концов, что вас обманули, вы можете только тайно заблокировать новость. Я недавно прочитал "Zizhitongjian" и нашел много таких случаев.
Во-первых, у них действительно есть такая потребность, во-вторых, они могут только придерживаться ее, потому что боятся, что эти вещи будут разоблачены и постыдны.
В мире нет ничего нового, и то же самое в индустрии программного обеспечения. Когда мы обожествляем вещь и наделяем ее какими-то сверхъестественными способностями, она может идти по пути алхимика все ровнее и ровнее.
Как обожествить? Ухватитесь за болевые точки, поговорите о видении и разработайте методологию, и вы, как правило, сможете успешно продавать.
Конечно, успех продаж — это только первый шаг, мы также должны избегать провалов и не заселяться осенью. Поэтому нужно мобилизовать энтузиазм лиц, принимающих решения, дать им осознать собственные недостатки и стыдиться признаться в собственных слабостях, а можно даже остепениться. Пока тот, кто принимает решения, находится на корабле, он найдет способы украсить его, бороться за дополнительные ресурсы и привлечь на борт больше людей.
Причина, по которой интернет-сленг так силен, заключается в том, что он может обмануть вас и сублимировать ваши мысли, а не пустые коды.
Я привожу пример здесь.
Есть компания с ограниченным количеством сотрудников НИОКР, но с большим количеством работы, которая разбросана по нескольким системам. Вывод, сделанный отделом исследований и разработок, таков: сосредоточиться и сконцентрироваться на основной системе. что делать? Не могу писать сухо на PPT聚焦Два слова, это кажется таким НИЗКИМ.
Подумав об этом, у меня внезапно появилась идея. Если нет, давайте составим несколько существительных. По уровню он делится на систему CVP, систему IVP и систему EVP. Таким образом, внезапно сила сильно возросла.
Не можете понять эти термины? Если вы этого не понимаете, это правильно, потому что я сделал это, и я хочу, чтобы я не понимал эффекта.
Глядя на картинку ниже, мы даже можем отнести ее к классификации системы по этим трем категориям.
Важно отметить, что центр бизнес-системы был преобразован и стал центром построения CVP. Ха-ха, мы можем говорить долго сейчас, по сравнению с решением закончить одним предложением.
«Учить вас говорить в течение десяти минут равносильно тому, что вы ничего не говорите». Это очень важная способность.
Итак, давайте посмотрим, что это за технологии? Почему опухоль? Зачем их обнимать.
Д не Д Д Д, какая разница?
Так называемый домен-ориентированный - это проектирование системы в соответствии с требованиями.Это предложение изначально ерунда.
У вас есть демо-код?
У вас есть демо-код?
У вас есть демо-код?
У вас есть демо-код?
Все нижеследующие статьи полны таких вопросов. Если уровень DDD только стратегически полезен, то он не должен попадать в поле зрения программиста, он должен быть игрушкой для аналитика требований. DDD следует изучить TOGAF, COBIT, CGEIT и другие тренинги, сосредоточиться на стратегической раскладке, не думать постоянно о жизни программиста и какой тактике.
Если вы сосредоточитесь на сертификатах бизнес-тренинга, вы заработаете свои деньги, а я сделаю свой архитектурный проект, и мы не будем превращать реку в воду. Но если ты поместишь свои щупальца в мое царство, ты привлечешь троллей вроде меня.
Правильный способ открыть DDD — включить его стратегическую фазу и полностью отказаться от тактической фазы. Делайте это, и вы будете жить комфортно. Простите меня за использование термина «ограниченный контекст» для объяснения: пока вы определяете границы моих сервисов, вам все равно, как я их потом реализую, паттерны проектирования и архитектурные паттерны, у меня много наборов инструментов, а не недостаток таких терминов, как CQRS и источник событий.
Концепция DDD зародилась в 2004 году, за столько лет она не была популярна, и ни один стандарт не был реализован, и не без причины. В последние годы некоторые люди обнаружили бесплодие технических терминов и снова взялись за них, надеясь, что они и дальше будут работать для KPI.
Раньше я был одержим DDD, и я был так взволнован, что меня мучило его прекрасное видение. Купила онлайн-курсы, купила книги и, в конце концов, обнаружила, что зря трачу время. Я ненавижу это. При всем уважении, сложное и сложно реализуемое техническое решение не годится для того, чтобы люди разделили свою энергию на его понимание.
Извините, нет возможности обратить поклонников.
Во-первых, DDD-компании — это компании, работающие по принципу «объем-в-объеме», и в отличие от микросервисной технологии они могут найти большое количество решений для внедрения. На самом деле, вы вряд ли найдете какие-либо ценные эталонные примеры, не говоря уже о том, чтобы дать друг другу пощечину. Это как Библия, она говорит вам, что правильно, но как это сделать, зависит от вашего понимания.
Почему вы не можете сделать DDD, а ваша команда не может сделать DDD? DDD приводит три основные причины.
-
Требования к команде высокие. Голос за кадром, если вы не можете сделать это хорошо, ваша команда не может этого сделать
-
Только сложные предприятия используют DDD, чтобы быть эффективными. Так что же такое сложность? Нет никакого заключения. Голос за кадром, вы думаете, что им непросто пользоваться, потому что ваш бизнес недостаточно сложен
-
Хотя вы не можете использовать DDD, содержащиеся в нем идеи все равно стоит изучить и обдумать. Голос за кадром, я панацея, я не дам тебе учиться зря
Никто не признает, что их команда плохая, ни одна команда не признает, что их бизнес прост, и никто не выдержит собственных вложений и по-настоящему побьет собаку мясными булочками. DDD мгновенно связывает вас вместе по нескольким причинам, по которым вы не можете дать пощечину.
В 2020 году на чтение книги «Realizing Domain-Driven Design» ушло целых три месяца, и я был поражен ее глубоким текстовым прикладным уровнем. В будущем, даже для простого CRUD-проекта, я знаю, как должна быть написана документация, и эта книга — очень хороший пример.
Вы ищите статьи DDD, неважно какая статья, есть одна характеристика, то есть вы плохо говорите человеческими словами. Весь код приложения — это куча неубедительного мусорного кода. Потому что разработчик сравнивает его с обычным методом написания и обнаруживает, что ищет вину, так зачем его использовать?
Возьмем очень популярную шестиугольную структуру.
Шестиугольная структура, поскольку она похожа на соты, выглядит очень близко к зеленой природе и очень высока. Честно говоря, я так и не понял, в чем разница между шестиугольной структурой, восьмиугольной структурой (такого не бывает) и треугольной структурой (такого не бывает), и почему эти существительные безумцы выбрали число 6.
Скажем прямо, сложная бизнес-логика не должна уделять слишком много внимания инфраструктуре, такой как технологии, но достаточно резервировать интерфейсы, она должна быть настолько загадочной, чтобы линии, как дождевые черви, выбегали из гнилого шестиугольника, расходились наружу. Как вы думаете, это красиво? Может быть, босс действительно так думает, потому что его радужное колесо существительного может действительно напугать группу скваттеров.
Не говорите, что плоскость данных и плоскость управления в ServiceMesh руководствуются DDD, хотя она концептуально основана.
На картинке ниже поиск в гуглеHexagonal ArchitectureПоявившаяся картинка.
Упс, а шестиугольники? Почему это изображение имеет 10-гранную форму? Это все еще шестиугольная структура? Вы обманываете своих детей? Когда я не умею считать? Что, вы снова называете это луковой архитектурой, это не одно и то же? Подобных недоразумений в DDD предостаточно, и я не хочу их объяснять, потому что это короткие рассказы. Это свидетельствует о том, что это комплексный метод накрутки, основанный на понятиях и сленге, а его пропагандисты не квалифицированы.
Вся концепция DDD имеет проблемы со значениями. Иными словами, замысел автора может быть и благим, и он ориентирован на сложное дело. В результате эта группа пропагандистов и обучения стала необходимым средством для решения проблемы.
Но мне очень жаль, у вас даже не было гладкого общения, по крайней мере, и вы не имеете права учить других заниматься архитектурой.
смущающая ситуация
Стыдно, что люди, которым действительно нужен DDD, не согласны с ним, люди, которым не нужен DDD, вынуждены с ним соглашаться.
Наибольшая ценность DDD заключается в сортировке бизнес-требований, разделении различных бизнес-доменов и формировании интерфейсов взаимодействия между доменами. Честно говоря, я видел много крупных боссов в консалтинговых компаниях, они насмехались над такой методологией желания забрать все, и они предпочитают использовать старомодные методы визитных карточек, такие как TOGAF. Но все дороги ведут в Рим, и окончательное территориальное деление еще можно согласовать.
Большинство этих процессов сортировки относятся к категории бизнес-экспертов и системных архитекторов. Результаты их работы будут реализованы в качестве входных и выходных данных для технической группы. Им нужен DDD, но их нет.
По сравнению с ним тактическая фаза DDD ничего не стоит. Например, объединение данных в широкую таблицу или большой центр обработки данных для формирования «средней платформы» данных обеспечивает разделение домена транзакций, домена управления и домена запросов.Мне не нужно знать концепцию CQRS, и это может работать очень хорошо. Насчет того, перегружена сущность или нет, я изначально был микросервисом, и гранулярность бизнеса изначально была небольшой. Как писать — моя свобода, а трансформация — мои собственные расходы. Мне не нужно следовать вашему набору. Говорите о деловой и технической коммуникации? Извините, я не видел команды, которая не умеет общаться и вести дела.
Лица, принимающие решения, вынуждают инженеров использовать тактику DDD для ведения бизнеса, что приводит к более запутанному коду и более частым изменениям. Но ДДД сказал: извините, это не моя вина, это провал вашей команды.
Правда это правда, а на самом деле некоторые до сих пор хвастаются и даже используют эту штуку для модификации кода. В книге «Шаблоны архитектуры микросервисов» даже есть две главы, «Источник событий» и «CQRS», в которых конкретно объясняется часть посадочного содержимого DDD. Это называется мастер отравил мастера, и, конечно, это также называется взаимной поддержкой.
При всем уважении, если верить этим глупостям, есть большая вероятность, что проект будет доведен до смерти. Лучше не иметь книг, чем верить в книги.Архитектура — это компромисс, и не существует универсального руководства. Вы можете ссылаться на него и думать об этом, но вы не можете скопировать его, потому что техническая предпосылка каждой компании различна.
Тем не менее, когда рекламируется какая-то концепция, а вы ее не принимаете, это может создать проблемы. В индустрии программного обеспечения есть две проблемы: одна заключается в том, как просто сообщать о сложных вещах, а другая — в том, как усложнять простые вещи. Для первого в основном опишите осуществимость вашей идеи. Что касается последнего, основная цель состоит в том, чтобы заставить людей чувствовать себя очень высоко, очень мейнстримно, и чем неяснее, тем лучше. Первый приземлен, а второй изрыгает цветы лотоса.
Последнее, очевидно, намного эффективнее первого. Звучит потрясающе, но если вы этого не понимаете, то можете получить аплодисменты и испытать чувство отчужденности. Никто не признается, что их IQ не в сети, и нужно заряжать этих людей энергией. Пока кто-то соглашается, могут быть преимущества.
Некоторые понятия и некоторые люди не являются богами, но общность интересов требует, чтобы они стали богами. У этой штуки тоже есть верующие, вы в это верите? Но разве инструменты разработки программного обеспечения не используются только тогда, когда они подходят, и выбрасываются, когда они не годятся? Зачем становиться верующим? Просто потому, что он на борту.
Друзья, в какой-то степени эти концепции DDD не отличаются от таких концепций, как биткойн. Это магия веры, это сила мастера!
End
Только такой честный человек, как я, может время от времени брызнуть. Потом развернулся и написал ДДД на своем плане. Да, я могу писать, я могу обсуждать, я могу думать, но я никогда не буду использовать это легкомысленно.
Только при рекламе я взорвусь как родной отец.
Об авторе: Miss Sister Taste (xjjdog), общедоступный аккаунт, который не позволяет программистам идти в обход. Сосредоточьтесь на инфраструктуре и Linux. Десять лет архитектуры, десятки миллиардов ежедневного трафика, обсуждение с вами мира высокой параллелизма, дающие вам другой вкус. Мой личный WeChat xjjdog0, добро пожаловать в друзья для дальнейшего общения.