1. Команда по выстраиванию отношений с разработчиками (Developer Relations Team) В названии прямо указано, что команда работает с конечными пользователями или покупателями (технологии)
Ма́рке́тинг (от англ. marketing «рыночная деятельность») — организационная функция и совокупность процессов создания, продвижения и предоставления продукта или услуги покупателям и управление взаимоотношениями с ними с выгодой для организации.
Другими словами DevRel это такие специальные маркетологи для разработчиков, конечная цель которых продать разработчикам продукт (язык программирвования, IDE, библиотеку, SaaS, whatever.). Все остальное по сути вода вокруг да около.
Это хорошо и я не осуждаю. Одно не понятно, зачем для этого придумали отдельные термины.
Все что нужно знать о качестве данного материала (речь не о переводе, а о оригинальной статье) — это кол-во референсов, первоисточников, ссылок на исследования и т.д.
Отсюда можно сделать и выводы:
— Спасибо Джеймс за ваше мнение, но выводы мы сделаем сами.
Перестаньте учить «технологии/платформы/инструменты». Это все равно что читать инструкции по профессиональному электроинструменту имея очень поверхностное понятие, зачем он вообще нужен и какие проблемы решает. С этим всем достаточно ознакамливаться. Параллельно практикуя решения тех или иных проблем.
Учить на мой взгляд нужно фундаментальные вещи, такие как: Архитектура Современных Компьютеров, Операционные Системы, Сети, Базы данных, Принципы построения языков программирования, Архитектуру ПО, Системный анализ, etc…
Имея фундаментальные знания во всех этих областях, прийдет понимание того какие проблемы решает та или иная технология/платформа и каким образом она это делает.
С этим пониманием с одной технологии/платформы/стека на другую при надобности вы сможете перескочить в промежутке 1-ого года.
К тому же в таком случае не будет подобного рода проблемм:
А во-вторых (и это главное), я не хочу знать, что такое ДэТэО, где оно лежит и как с ним работать. Мне нужен только путь, метод, параметры и набор ответа. В терминах HTTP/REST.
Потому что и DTO и REST и HTTP — термины вне технологий вне фронтэнда/бэкэнда, вне языков программирования.
А вот когда я в чём то убеждён, а все делают по-другому, Меня подбамбливает и я сажусь писать об этом, как вижу.
Я тоже был в чем то таким как вы. Примерно лет 5 назад. Меня тоже в свое время подобным образом бомбило. К сожалению или к счастью (я не знаю) я не писал об этом а посему такое вот мое видение мира не вышло в свет.
Про пользу комании — я лично, клал на неё. Антоха вот нет
Вы можете мне не верить, но рано или поздно вы пересмотрите этот вопрос. Причем чем раньше это случится, тем успешнее будет ваша карьера (Но это не точно).
Мне тоже раньше было срать, а потом мне пришлось встать «по другую сторону баррикад». Cобрать команду, возглавить разработку, поработать CTO.
Сейчас я снова работаю разработчиком. И не потому что меня уволили, менеджеры идиоты или я не справился с обязанностями, а потому что я люблю эту профессию и пока еще не «напрограммировался».
Но в отличие от меня старого, моя картина мира существенным образом изменилась и сейчас мне не срать, чего и вам желаю… И если вы не верите мне, почитайте хотя бы книги которые я давал выше. Они написаны людьми которые в профессии гораздо дольше вас и меня. Поверьте, они знают о чем пишут. Вы не раз найдете там себя…
Ваш труд, как статья не говно, наоборот все ваши посты взрывают рейтинги и это определенно талант, писать так, чтобы у всех бомбило.
Проблему я вижу в посыле который вы несете и в созданном вами образе. Вот этот ваш образ «Разработчика бунтаря. Рок-звезды, которую менеджмент не понимает» ни одной компании не принес ни чего хорошего.
Ознакомился я тут с авторами статьи. Все авторы (arttom, fillpackart, rcanedu) подписаны друг на друга.
arttom «Редактор» и работает в компании «Мой Круг». Подписан на 3-ех пользователей. 2 из которых авторы данной статьи. fillpackart подписан на Хабре на 6 человек, 2 из которых авторы данной статьи. Так же подписан на baragol который работает в Хабре и тоже является «Редактором». rcanedu подписан на Хабре на 3 человек, 2 из которых авторы данной статьи.
Твиттеры fillpackart и rcanedu заведены в 2019 году. В одном из них набита куча постов для «видимости» в другом нет практически ничего кроме ссылок на статьи на Хабре. GitHub аккаунты fillpackart и rcanedu в общем то практически пусты. Т.е. посмотреть реальный код авторов (или вклад в OpenSource) не представляется возможным.
Резюме в паблике, на том же МоемКруге или лучше на LinkedIn найти тоже не получилось. Нашел только резюме fillpackart на каком то левом сайте. Но там в общем то ни чего особенного. Обычное резюме обычного разработчика. Это то что мы имеем с одной стороны.
С другой стороны. Все статьи fillpackart, достаточно качественно написаны и оформлены. одинаковый стиль написания, повествования, иллюстраций. Все они имеют «кричащие заголовки» и написаны на «злободневные темы», вызывающие горячие споры. Статьи rcanedu так же похожи по оформлени, стилистике и заголовкам. Как результат у товарища fillpackart неимоверно высокие показатели кармы и рейтинга (а еще расхождение в дате регистрации и дате «приглашения» на сайт. Зарегестрирован на 2 года раньше чем приглашен. Ума не приложу, как такое возможно). rcanedu приглашен товарищем fillpackart и не смотря на то что он имеет только 2 публикации, рейтинги этих статей зашкаливают.
Фух. Три с лишним месяца работы — и техническая статья готова.
Захерачили с пацанами на Хабр
Как я понимаю 3 месяца работы над статьей?
Интересная получается ситуация. Как минимум все авторы друзья. Но скорее всего ребята просто коллеги и работают вместе в качестве IT журналистов. В целом это не плохо. Плохо другое. Плохо выдавать себя за «высококлассного эксперта отрасли» имея суммарно 6 лет опыта работы в этой самой отрасли публикуя статьи, единственная цель которых — поднятие траффика и заработок. Еще хуже то, что большинство разработчиков на подобные статьи ведуться тем самым создавая им рейтинг. А некоторые еще и пытаются применять полученные «знания» при построении карьеры.
В общем данная ситуация завставила меня по другому взглянуть на Хабр. Теперь я понимаю, почему некоторые статьи на профессиональные темы в области разработки частенько остаются здесь недооценены а иногда и заганяются в минуса. Я на 100% убежден в том, что не стоит рассматривать Хабр как профессиональное сообщество. Очень жаль, что из сообщества IT-профессионалов Хабр превратился в обычное технологическое СМИ.
PS. И да ребят, вы когда минусуете не нравящиеся вам коменты, договоритесь, кто кого минусует, а то в целом ряде комментов ровно по 3 минуса…
Я повесил у себя в подвале боксерскую грушу, приклеил на нее стоковое фото типичного менеджера и запихал внутрь динамик, чтобы он проигрывал фразы, которые меня злят.
Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.
Поэтому, вместо узкозаточенной либы, на которую стоял таск, мы решили делать гораздо более мощную и абстрактную — подходящую для всего. И мы невероятно верили в свою правоту, потому что только так и создаются по-настоящему хорошие вещи.
Вторая ошибка. Вместо решения поставленой бизнесом задачи вы решили послать всех к чертям и за счет бизнеса реализовать свои амбиции.
Чтобы делать хорошие дела, надо уметь убеждать людей в своей правоте.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Когда делаешь фронт, есть два источника проблем — пользователь и бекенд.
Четвертая ошибка. Не то ни другое не является проблемой. Пользователи — это те без кого ваша работа не имеет смысла, бэкэнд — это те без кого вы не сможете решить большинство сложных задач современного мира требующих большого кол-ва вычислительных мощностей.
… Но такие придурки существуют, причём существуют в том же самом мире, где есть другие придурки, пропускающие это говно на кодревью.
… Но мы сделаем, потому что мы профессионалы…
… и дураки легко сломают наш код.
Пятая ошибка. Считать всех вокруг придурками, идиотами, дураками, при этом считать себя профессионалами.
Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами
В завершении ожидаемый и закономерный результат. Жизнь все расставила по местам.
К чему я это все? Я бы рекомендовал вам к прочтению вот эти книги. Все они в меньшей степени про код и в большей степени про то, как перестать доказывать всем, что ты профессионал и стать профессионалом:
The Pragmatic Programmer: From Journeyman to Master (by Andrew Hunt_
The Passionate Programmer: Creating a Remarkable Career in Software Development (by Chad Fowler)
Soft Skills: The software developer's life manual (by John Sonmez)
The Clean Coder: A Code of Conduct for Professional Programmers (by Robert C. Martin)
но при этом вся бизнес-логика собрана в одном слое
Этот слой по сути и есть ваша «модель предметной области». Не данные которыми вы оперируете, а поведение. Ваша анемичная модель — статическая структура не имеющая для бизнеса ни какой ценности сама по себе и не выполняющая никакой работы. Это просто «данные».
Мне кажется что здесь вы слегка искажаете понятие «Предметная область».
«User Interface» — как мне кажется не является предметной областью до тех пор пока вы не разрабатываете UI библиотеки и/или фреймворки.
Грубо говоря, если вы разрабатываете приложение для «Банкинга», ваша предметная область: «Банкинг». Модель в этом случае реализована только на сервере. UI всего лишь рендерит результаты модели которые приходят в «удобном виде» через API. Вы всего лишь используете UI библиотеку чтобы построить UI банковского приложения.
Предметная область (домен) — это всегда о том, какую вы проблему пытаетесь решить разрабатывая приложение в целом (Нужно задать вопросы: Зачем я пишу эту программу? Кому она поможет? Для какой она сферы? Это и есть предметная область.).
Когда вы разрабатываете приложение для банкинга, вы не решаете проблему изобретения UI компонентов. То как реализован UI, как он рендерится операционной системой и т.п. вне вашей предметной области.
Эту задачу за вас решили разработчики вашей операционки.
Это для них, а точнее для отдела пользовательских интерфейсов «UI» является предметной областью.
Все эти концепции давно подробно описаны. Статья является попыткой донести до коллег по цеху важность понимания этих самых концепций. Другими словами я хочу сказать следующее: — Не нужно изобретать велосипеды, и вкладывать в данные концепции свой смысл. Он давно вложен и подробно описан. Все что нужно сделать, это изучить их и пользуясь своей головой применять на практике, там где это необходимо.
Да нет, я убежден в том, что бизнес-логику реально выделить в отдельный слой и имел возможность сделать это на практике. Я это проверял, это работает.
Нет никаких полностью абстрактных бизнес-логик.
Вы правы, бизнес-логика той или иной предметной области вполне конкретна. Я и не говорю про существование «абстрактных бизнес логик». Я просто говорю об общих принципах.
Если между хранилищем и бизнес логикой сделать очень хорошую изоляция в 99% это будет тормозить, т.к. вы не сможете использовать фичи хранилища или ваше приложение будет немасштабируемое. Нельзя всё взять и поделить.
Не нужно все возводить в абсолют. Выделить бизнес-логику в отдельный слой вполне реально. Иногда конечно целесообразно выделить только какую-то часть. Или например отвязать бизнес-логику от сети, но не отвязывать от хранилища. Но тем не менее.
Вот вам пример. В Kubernetes большая часть бизнес-логики изолирована и сосредоточена в пакете pkg/controller (а точнее его подпакетах). Если вы внимательно исследуете код, вы обнаружите, что этот слой практически полностью отделен от реализации набором интерфейсов.
Всегда нужно думать.
Абсолютно с вами согласен, именно поэтому я и делюсь мыслями, чтобы еще раз подумать самому и дать подумать другим.
Но на это можно посмотреть и так, что в приложении есть чисто данные — данные без поведения, а есть слой кода, который имплементирует бизнес-логику, которая оперирует данными так или иначе.
Именно. Основная моя мысль заключается в том, что по сути «модель предметной области» во первых сосоит из данных и поведения (не важно, они вместе или нет), а во вторую, определяется в первую очередь поведением. Если вы отделите данные и не будете реализовавать «бизнес-логику» как набор классов, модель предметной области ни куда не денется. Даже в случае если вы растащите логику по разным «инфраструктурным сущностям». Она будет существовать, просто в неявном виде (внутри инфраструктурного кода).
“Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению
Это к слову мой перевод вот этого предложения из статьи Фаулера про анемичную модель:
The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk.
Это чат. По сути комьюнити. Оно открыто, но специфиика Слэка в том что надо зарегестрироваться, после чего поставить приложений и войти. Ссылка в Slack добавлена на случай, если вдруг кто-нибудь из сообщества решит проверить, что цитаты не искажены и слова не переиначены :)
Если вы пилите кнопку с логикой для банковского приложения, имея в виду именно полную реализацию процедуры «снятие наличных»
Нет, реализацию процедуры «снятие наличных» я не имел ввиду.Я считаю эту процедуру всего лишь часть предметной области «Банкинг».
вы работаете в доменной модели фронтэнда, дергающего API
Правильно ли я понимаю, что предметная область в данном случае:
— Фронтэнд дергающий API
А если вы пилите кастомную кнопку, которая потом будет использоваться в том числе и в контексте снятия наличных — вам вообще пофиг на доменную модель верхнего уровня...
Вы правы. В данном случае вас как разработчика интерфейса доменная модель не интересует. Только не могу понять, чем отличается доменная модель верхнего уровня и нижнего уровня? Можете раскрыть данные определения? Или дать хотя бы ссылки где можно об этом почитать?
Ну можно же привести пример «предметной области» для человека пилящего кнопочку или UI компонент?
К примеру если вы разрабатываете ядро библиотеки `React` (или реализуете компонент Button в ядре этой библиотеки) предметной областью для вас будет:
— UI библиотеки для Web
Но если вы на базе `React`рисуете кнопку «Снять наличные», для банковского приложения. Это домен «Banking», и вы как фронэндщик пользуетесь моделью доменного уровня через API. И это не зависит не от масштаба, не от точки зрения.
Так же, если вы разрабатываете iOS, предметная область будет:
— Операционные системы для мобильных платформ
Но если вы решаете с помощью компьютера бизнес-задачи, домен будет отражать бизнес функции.
1. Команда по выстраиванию отношений с разработчиками (Developer Relations Team) В названии прямо указано, что команда работает с конечными пользователями или покупателями (технологии)
Другими словами DevRel это такие специальные маркетологи для разработчиков, конечная цель которых продать разработчикам продукт (язык программирвования, IDE, библиотеку, SaaS, whatever.). Все остальное по сути вода вокруг да около.
Это хорошо и я не осуждаю. Одно не понятно, зачем для этого придумали отдельные термины.
Интересно что этот "менеджмент на основе данных" предусмотрительно не стал анализировать менеджеров... :D
Отсюда можно сделать и выводы:
— Спасибо Джеймс за ваше мнение, но выводы мы сделаем сами.
Учить на мой взгляд нужно фундаментальные вещи, такие как: Архитектура Современных Компьютеров, Операционные Системы, Сети, Базы данных, Принципы построения языков программирования, Архитектуру ПО, Системный анализ, etc…
Имея фундаментальные знания во всех этих областях, прийдет понимание того какие проблемы решает та или иная технология/платформа и каким образом она это делает.
С этим пониманием с одной технологии/платформы/стека на другую при надобности вы сможете перескочить в промежутке 1-ого года.
К тому же в таком случае не будет подобного рода проблемм:
Потому что и DTO и REST и HTTP — термины вне технологий вне фронтэнда/бэкэнда, вне языков программирования.
Я тоже был в чем то таким как вы. Примерно лет 5 назад. Меня тоже в свое время подобным образом бомбило. К сожалению или к счастью (я не знаю) я не писал об этом а посему такое вот мое видение мира не вышло в свет.
Вы можете мне не верить, но рано или поздно вы пересмотрите этот вопрос. Причем чем раньше это случится, тем успешнее будет ваша карьера (Но это не точно).
Мне тоже раньше было срать, а потом мне пришлось встать «по другую сторону баррикад». Cобрать команду, возглавить разработку, поработать CTO.
Сейчас я снова работаю разработчиком. И не потому что меня уволили, менеджеры идиоты или я не справился с обязанностями, а потому что я люблю эту профессию и пока еще не «напрограммировался».
Но в отличие от меня старого, моя картина мира существенным образом изменилась и сейчас мне не срать, чего и вам желаю… И если вы не верите мне, почитайте хотя бы книги которые я давал выше. Они написаны людьми которые в профессии гораздо дольше вас и меня. Поверьте, они знают о чем пишут. Вы не раз найдете там себя…
Проблему я вижу в посыле который вы несете и в созданном вами образе. Вот этот ваш образ «Разработчика бунтаря. Рок-звезды, которую менеджмент не понимает» ни одной компании не принес ни чего хорошего.
arttom «Редактор» и работает в компании «Мой Круг». Подписан на 3-ех пользователей. 2 из которых авторы данной статьи.
fillpackart подписан на Хабре на 6 человек, 2 из которых авторы данной статьи. Так же подписан на baragol который работает в Хабре и тоже является «Редактором».
rcanedu подписан на Хабре на 3 человек, 2 из которых авторы данной статьи.
Твиттеры fillpackart и rcanedu заведены в 2019 году. В одном из них набита куча постов для «видимости» в другом нет практически ничего кроме ссылок на статьи на Хабре. GitHub аккаунты fillpackart и rcanedu в общем то практически пусты. Т.е. посмотреть реальный код авторов (или вклад в OpenSource) не представляется возможным.
Резюме в паблике, на том же МоемКруге или лучше на LinkedIn найти тоже не получилось. Нашел только резюме fillpackart на каком то левом сайте. Но там в общем то ни чего особенного. Обычное резюме обычного разработчика. Это то что мы имеем с одной стороны.
С другой стороны. Все статьи fillpackart, достаточно качественно написаны и оформлены. одинаковый стиль написания, повествования, иллюстраций. Все они имеют «кричащие заголовки» и написаны на «злободневные темы», вызывающие горячие споры. Статьи rcanedu так же похожи по оформлени, стилистике и заголовкам. Как результат у товарища fillpackart неимоверно высокие показатели кармы и рейтинга (а еще расхождение в дате регистрации и дате «приглашения» на сайт. Зарегестрирован на 2 года раньше чем приглашен. Ума не приложу, как такое возможно). rcanedu приглашен товарищем fillpackart и не смотря на то что он имеет только 2 публикации, рейтинги этих статей зашкаливают.
Вот кстати что пишет в своем твиттере по поводу данной статьи товарищ fillpackart:
Как я понимаю 3 месяца работы над статьей?
Интересная получается ситуация. Как минимум все авторы друзья. Но скорее всего ребята просто коллеги и работают вместе в качестве IT журналистов. В целом это не плохо. Плохо другое. Плохо выдавать себя за «высококлассного эксперта отрасли» имея суммарно 6 лет опыта работы в этой самой отрасли публикуя статьи, единственная цель которых — поднятие траффика и заработок. Еще хуже то, что большинство разработчиков на подобные статьи ведуться тем самым создавая им рейтинг. А некоторые еще и пытаются применять полученные «знания» при построении карьеры.
В общем данная ситуация завставила меня по другому взглянуть на Хабр. Теперь я понимаю, почему некоторые статьи на профессиональные темы в области разработки частенько остаются здесь недооценены а иногда и заганяются в минуса. Я на 100% убежден в том, что не стоит рассматривать Хабр как профессиональное сообщество. Очень жаль, что из сообщества IT-профессионалов Хабр превратился в обычное технологическое СМИ.
PS. И да ребят, вы когда минусуете не нравящиеся вам коменты, договоритесь, кто кого минусует, а то в целом ряде комментов ровно по 3 минуса…
Первая ошибка. Вместо того чтобы считать менеджеров «идиотами» следовало бы научится их слушать и правильно интерпретировать то что они пытаются донести.
Вторая ошибка. Вместо решения поставленой бизнесом задачи вы решили послать всех к чертям и за счет бизнеса реализовать свои амбиции.
Третья ошибка. Чтобы делать хорошин дела, нужно чтобы эти дела приносили людям пользу. В таком случае, не придется ни кого ни в чем убеждать.
Четвертая ошибка. Не то ни другое не является проблемой. Пользователи — это те без кого ваша работа не имеет смысла, бэкэнд — это те без кого вы не сможете решить большинство сложных задач современного мира требующих большого кол-ва вычислительных мощностей.
Пятая ошибка. Считать всех вокруг придурками, идиотами, дураками, при этом считать себя профессионалами.
В завершении ожидаемый и закономерный результат. Жизнь все расставила по местам.
К чему я это все? Я бы рекомендовал вам к прочтению вот эти книги. Все они в меньшей степени про код и в большей степени про то, как перестать доказывать всем, что ты профессионал и стать профессионалом:
Этот слой по сути и есть ваша «модель предметной области». Не данные которыми вы оперируете, а поведение. Ваша анемичная модель — статическая структура не имеющая для бизнеса ни какой ценности сама по себе и не выполняющая никакой работы. Это просто «данные».
«User Interface» — как мне кажется не является предметной областью до тех пор пока вы не разрабатываете UI библиотеки и/или фреймворки.
Грубо говоря, если вы разрабатываете приложение для «Банкинга», ваша предметная область: «Банкинг». Модель в этом случае реализована только на сервере. UI всего лишь рендерит результаты модели которые приходят в «удобном виде» через API. Вы всего лишь используете UI библиотеку чтобы построить UI банковского приложения.
Предметная область (домен) — это всегда о том, какую вы проблему пытаетесь решить разрабатывая приложение в целом (Нужно задать вопросы: Зачем я пишу эту программу? Кому она поможет? Для какой она сферы? Это и есть предметная область.).
Когда вы разрабатываете приложение для банкинга, вы не решаете проблему изобретения UI компонентов. То как реализован UI, как он рендерится операционной системой и т.п. вне вашей предметной области.
Эту задачу за вас решили разработчики вашей операционки.
Это для них, а точнее для отдела пользовательских интерфейсов «UI» является предметной областью.
То что выражено в коде как UseCases, является частью «модели предметной области».
Все эти концепции давно подробно описаны. Статья является попыткой донести до коллег по цеху важность понимания этих самых концепций. Другими словами я хочу сказать следующее: — Не нужно изобретать велосипеды, и вкладывать в данные концепции свой смысл. Он давно вложен и подробно описан. Все что нужно сделать, это изучить их и пользуясь своей головой применять на практике, там где это необходимо.
Да нет, я убежден в том, что бизнес-логику реально выделить в отдельный слой и имел возможность сделать это на практике. Я это проверял, это работает.
Вы правы, бизнес-логика той или иной предметной области вполне конкретна. Я и не говорю про существование «абстрактных бизнес логик». Я просто говорю об общих принципах.
Не нужно все возводить в абсолют. Выделить бизнес-логику в отдельный слой вполне реально. Иногда конечно целесообразно выделить только какую-то часть. Или например отвязать бизнес-логику от сети, но не отвязывать от хранилища. Но тем не менее.
Вот вам пример. В Kubernetes большая часть бизнес-логики изолирована и сосредоточена в пакете pkg/controller (а точнее его подпакетах). Если вы внимательно исследуете код, вы обнаружите, что этот слой практически полностью отделен от реализации набором интерфейсов.
Абсолютно с вами согласен, именно поэтому я и делюсь мыслями, чтобы еще раз подумать самому и дать подумать другим.
Именно. Основная моя мысль заключается в том, что по сути «модель предметной области» во первых сосоит из данных и поведения (не важно, они вместе или нет), а во вторую, определяется в первую очередь поведением. Если вы отделите данные и не будете реализовавать «бизнес-логику» как набор классов, модель предметной области ни куда не денется. Даже в случае если вы растащите логику по разным «инфраструктурным сущностям». Она будет существовать, просто в неявном виде (внутри инфраструктурного кода).
Это к слову мой перевод вот этого предложения из статьи Фаулера про анемичную модель:
Нет, реализацию процедуры «снятие наличных» я не имел ввиду.Я считаю эту процедуру всего лишь часть предметной области «Банкинг».
Правильно ли я понимаю, что предметная область в данном случае:
— Фронтэнд дергающий API
Вы правы. В данном случае вас как разработчика интерфейса доменная модель не интересует. Только не могу понять, чем отличается доменная модель верхнего уровня и нижнего уровня? Можете раскрыть данные определения? Или дать хотя бы ссылки где можно об этом почитать?
К примеру если вы разрабатываете ядро библиотеки `React` (или реализуете компонент Button в ядре этой библиотеки) предметной областью для вас будет:
— UI библиотеки для Web
Но если вы на базе `React`рисуете кнопку «Снять наличные», для банковского приложения. Это домен «Banking», и вы как фронэндщик пользуетесь моделью доменного уровня через API. И это не зависит не от масштаба, не от точки зрения.
Так же, если вы разрабатываете iOS, предметная область будет:
— Операционные системы для мобильных платформ
Но если вы решаете с помощью компьютера бизнес-задачи, домен будет отражать бизнес функции.
Я например выделяю такие домены (предметные области):
— Shipping (Перевозка грузов)
— Banking (Банковские услуги)
— Booking (Продажа билетов)