Или вы говорите, что мне надо писать свой Apigee только потому что DDD не позволяет создать какой-то класс в Domain, и по нему что-то генерировать?
А в CRM мне значит нельзя сразу мои объекты в таблицы ложить из Domain, а надо сделать виртуальные таблицы, чтобы в рантайме можно было создавать таблицы и связи, и только потом работать с таким CRM?
Да, может имеет смысл описывать WebApi (хоть и как-то видоизмененно) не только потому что система из цикла статей - Apigee, и это точно доменная сущность.
Может даже стоит вынести описание контрактов )
Формализовать контракт: Необходимо создать чёткий интерфейс взаимодействия между контекстами и определить способы взаимодействия между контекстами.
Выражений проекта "в реальном мире" пока два - Web и консольное приложение (где воркеры будут из шины читать).
В реальном проекте - или выделю Domain.* и Generators.* в отдельный репозиторий\пакет и буду всюду подключать (или придумаю еще что-нибудь, вертикальные слайсы например). Или даже дерево доменных проектов, и контейнеры (с воркерами\webApi) в infrastructure.
В рамках цикла статей я не буду на этом акцентировать внимание.
В конце концов какая разница бизнесу, какой у вас там путь к эндпойнту (только если конечно ваш бизнес не Apigee
Apigee :)
Берете Web API, подключаете к нему генератор
Какое веб-апи?
Я объектом на едином языке в рамках домена задаю требование заказчика - конечная точка WebApi. Тут многие привыкли видеть или документ (объект), или документы и какие-то правила их валидации. Но задание просто конечной точки - тоже вполне валидный вариант (потому что это - основа проекта, и без WebApi никакого сбора данных из 100 источников не будет. И замены WebApi на шины тоже не будет).
Все остальное (DTO, код в Infrastructure и application) генерируется.
Да, задание объектом было бы логичнее, но менее удобно для статьи (мне не нужно через Web конструктор добавлять endpoint-ы, они добавляются раз в неделю\месяц. Задание Api динамически объектами - скорее всего очень много лишней писанины). Да и вообще статья о кодогенерации ).
Как я буду разделять конфигурации (какие воркеры запускать, какое API поднимать) - еще не думал. Думаю через атрибуты :).
Я об этом позавчера и написал - да, я перенес WebApi в доменную область.
Это - предметная область (Вот такое WebApi, надо по 3-4 таблицам с кучи конечных точек все раскладывать. Таблицы хоть в mongo, хоть в SQL. И отображение - хоть WPF хоть MVC. Интеграции то ли будут, то ли не будут).
И я даже отделил описание предметной области (объект конфигурации) от физической реализации в Infrastructure.
Их волнуют данные (которые 100% описаны) и работа с ними, вот вам и доменная модель
Конечные точки Web-Api их волнуют.
Какие-то непонятные рассуждения про бизнес.
Зашли рассказать, что не понимаете DDD, и испортить впечатление от публикаций?
Вам еще вчера написали, что вы даже не можете внятно описать, что не так, а просто несете ахинею.
При этом ахинея звучит довольно вызывающе (даже типично) - Вы дурак, DDD - это проявление Высшей Божественной Воли, и нельзя никак измерить и описать DDD!
Не читали определений\статей\публикаций, а лезете со своей кривой мордой.
conceptual model aims to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts.
Бизнес какой?
Принять данные по указанным точкам WebApi (прямо оборудования сотни тысяч единиц, на миллионы), и занести в таблицы? (А потом привести к единому виду (etl) и отобразить?)
Это и есть предметная область. В которой есть заказчики (эксперты доменной области).
In the field of computer science a conceptual model aims to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts.
Увы, я вам сказал что в моем цикле публикаций конечные точки - предметная область. И в моем случае эта "инфраструктура" гарантированно не будет меняться в течении всего времени жизни приложения.
И у меня даже есть отделение доменной области (приходит Вася и говорит - новое оборудование вот по таким конечным точкам связывается)
от непосредственно реализации этих конечных точек.
Домен - это данные и правила их трансформации; а так же машина состояний бизнес процесса
Я вам тоже сказал, я захотел и выбрал такую предметную область.
Такая предметная область существует.
В этой предметной области запросы - не Infrastructure, а основа всей системы (уровень Domain. Прямо физическое оборудование, нерушимое, без смены протоколов (и со сменой, но не везде)). И запросы только расширяются (не изменяются).
Я не делаю СЭД.
Выбор предметной области это вообще вопрос философский.
DDD - не материально, или эта концепция как-то отражается в нашем, материальном мире? (В структуре проектов, зависимостях, функциональном наполнении?)
Почему бы вам просто не написать 3 - Мне не понравилось описание предметной области. (Потому что вы делаете СЭД и привыкли к тому, что WebApi - Infrastructure?)
Вот так это как? Просто условный JSON вам показали? Или все-таки есть какое-то описание данных, которые, я так пологаю, надо обработать?
Я обозначил такую предметную область. Запросы не меняются.
Я не собираюсь писать "Генератор, превращающий WebApi вашей еле работающей СЭД в Амазон".
А вы запросы обрабатываете как-то? Ну всмысле перед записью в базу логика есть какая-то? Или просто перекладываете туда-сюда?
Нет, об этом написано в первой статье. Вы их читаете или сразу приходите что-то обьяснять? Может, вы даже не понимаете ООП.
Да и темболее, смотрите, у вас аналитики отправлял по HTTP запросы, потом условно перешли на ВебСокеты для мониторинга в реальном времени и вы выкидываете ваши генераторы кода HTTP объектов (самой важной доменной области в приложении) и пишете новые для веб сокетов)) Это конечно же не DDD, а вы так говорите будто понимаете и сейчас тут будете всем объяснять)
Тут по описанию предметной области такой переход не возможен (только расширение API, суровый IOT).
В СЭД: Это аномальное явление - если меняю инфраструктуру переписываю генераторы инфраструктуры.
Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ.domain-driven design, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей.
У нас предметная область какая?
Запросы - Вот мы и создали объекты для описания HTTP запросов в Domain.
Далее, на основе описания нашей пока скудной предметной области при помощи генераторов пишем весь Boilerplate (контроллеры в Infrastructure, воркеры в Application, DTO в Application).
Спорить с Вами дальше не буду - прошлый проект показывали даже ребятам из Росатома, сказали круто ).
Если будет время - напишу цикл по BoilerTemplate своими руками (прямо с обьектами ORM и flow в домене, чтобы даже плохо разбирающиеся в DDD люди понимали о чем речь).
И как вы предлагаете делать кодогенерацию?
Или вы говорите, что мне надо писать свой Apigee только потому что DDD не позволяет создать какой-то класс в Domain, и по нему что-то генерировать?
А в CRM мне значит нельзя сразу мои объекты в таблицы ложить из Domain, а надо сделать виртуальные таблицы, чтобы в рантайме можно было создавать таблицы и связи, и только потом работать с таким CRM?
Значит ли это, что создатели ABP - полные дураки?
Ведь там эти, доменные сущности приходится в коде создавать и перекомпилировать проект.
Это из разряда Один "эксперт" по DDD уже ушел
Теперь вот вы. Вы же в соседней статье даже ссылку на Apigee привели.
Скажите, в Apigee у нас конечные точки WebApi - Доменная сущность или нет?
А если вы в общем - https://habr.com/ru/articles/922418/
Отсутствие четких контрактов и API.
Да, может имеет смысл описывать WebApi (хоть и как-то видоизмененно) не только потому что система из цикла статей - Apigee, и это точно доменная сущность.
Может даже стоит вынести описание контрактов )
Выражений проекта "в реальном мире" пока два - Web и консольное приложение (где воркеры будут из шины читать).
В реальном проекте - или выделю Domain.* и Generators.* в отдельный репозиторий\пакет и буду всюду подключать (или придумаю еще что-нибудь, вертикальные слайсы например). Или даже дерево доменных проектов, и контейнеры (с воркерами\webApi) в infrastructure.
В рамках цикла статей я не буду на этом акцентировать внимание.
Классом.
Задание объектами как в Apigee было бы логичнее, но слишком муторно в плане бойлерплейта и не нужно.
Apigee :)
Какое веб-апи?
Я объектом на едином языке в рамках домена задаю требование заказчика - конечная точка WebApi. Тут многие привыкли видеть или документ (объект), или документы и какие-то правила их валидации. Но задание просто конечной точки - тоже вполне валидный вариант (потому что это - основа проекта, и без WebApi никакого сбора данных из 100 источников не будет. И замены WebApi на шины тоже не будет).
Все остальное (DTO, код в Infrastructure и application) генерируется.
Да, задание объектом было бы логичнее, но менее удобно для статьи (мне не нужно через Web конструктор добавлять endpoint-ы, они добавляются раз в неделю\месяц. Задание Api динамически объектами - скорее всего очень много лишней писанины). Да и вообще статья о кодогенерации ).
Как я буду разделять конфигурации (какие воркеры запускать, какое API поднимать) - еще не думал. Думаю через атрибуты :).
Конфигурировать скорее всего буду стандартно через https://learn.microsoft.com/ru-ru/dotnet/core/extensions/configuration.
Ценник сбивают.
Никто не пишет статьи "Это был идеальный проект, но его закрыли. Вы не поверите, почему"
Я об этом позавчера и написал - да, я перенес WebApi в доменную область.
Это - предметная область (Вот такое WebApi, надо по 3-4 таблицам с кучи конечных точек все раскладывать. Таблицы хоть в mongo, хоть в SQL. И отображение - хоть WPF хоть MVC. Интеграции то ли будут, то ли не будут).
И я даже отделил описание предметной области (объект конфигурации) от физической реализации в Infrastructure.
https://habr.com/ru/articles/921552/#comment_28483466
Мда.
Их не смущает, что современные симуляторы роста тканей уже довольно отлично предсказывают всю регуляцию экспрессии генов? (Кибергенетика)
А с графами взаимодействий отлично справляется Nvidia Microbes.
Конечные точки Web-Api их волнуют.
Какие-то непонятные рассуждения про бизнес.
Зашли рассказать, что не понимаете DDD, и испортить впечатление от публикаций?
Вам еще вчера написали, что вы даже не можете внятно описать, что не так, а просто несете ахинею.
При этом ахинея звучит довольно вызывающе (даже типично) - Вы дурак, DDD - это проявление Высшей Божественной Воли, и нельзя никак измерить и описать DDD!
У вас не DDD! Где DDD?
https://habr.com/ru/articles/921552/#comment_28483466
Тебе уже 10 раз написали про доменную модель.
Не читали определений\статей\публикаций, а лезете со своей кривой мордой.
Бизнес какой?
Принять данные по указанным точкам WebApi (прямо оборудования сотни тысяч единиц, на миллионы), и занести в таблицы? (А потом привести к единому виду (etl) и отобразить?)
Это и есть предметная область. В которой есть заказчики (эксперты доменной области).
А я думаю вы с @SolidSnack даже не читали определений (или кучи публикаций\книг), а используете ChatGPT.
Прочитайте хотя бы определение.
https://en.wikipedia.org/wiki/Domain_model
https://habr.com/ru/articles/453906/
Увы, я вам сказал что в моем цикле публикаций конечные точки - предметная область. И в моем случае эта "инфраструктура" гарантированно не будет меняться в течении всего времени жизни приложения.
И у меня даже есть отделение доменной области (приходит Вася и говорит - новое оборудование вот по таким конечным точкам связывается)
от непосредственно реализации этих конечных точек.
https://habr.com/ru/articles/921552/#comment_28483466
Это для СЭД. И я видел более трех команд, не понимающих DDD даже на уровне СЭД (как раз объекты и переходы).
Я реализовал крутую кодогенерацию в DDD на C#.
При чем тут Orleans?
Все то, о чем вы пытаетесь написать уже пишет ChatGPT, ChatRTX, DeepSeek и Clippy.
(del)
https://habr.com/ru/articles/921552/#comment_28483466
Люди делятся на 2 типа - со способностью к абстрактному мышлению и без таковой.
Я ФОРМЫ ДЕЛАЛ! И ДЕЛАЮ ФОРМЫ! ДЛЯ СЭД! У МЕНЯ HTTP - INFRASTRUCTURE! DDD КАЖДЫЙ ДЕНЬ!Я вам тоже сказал, я захотел и выбрал такую предметную область.
Такая предметная область существует.
В этой предметной области запросы - не Infrastructure, а основа всей системы (уровень Domain. Прямо физическое оборудование, нерушимое, без смены протоколов (и со сменой, но не везде)). И запросы только расширяются (не изменяются).
Я не делаю СЭД.
Выбор предметной области это вообще вопрос философский.
Я полностью с Вами согласен.
Время специалистов стоит дорого.
DDD - не материально, или эта концепция как-то отражается в нашем, материальном мире? (В структуре проектов, зависимостях, функциональном наполнении?)
Почему бы вам просто не написать 3 - Мне не понравилось описание предметной области. (Потому что вы делаете СЭД и привыкли к тому, что WebApi - Infrastructure?)
Вот и нашли человека, не понимающего DDD )
Что вам не понравилось?
1) Структура проекта
2) Зависимости между проектами
3) Описание предметной области задачи
4) Как сделана генерация
Введите одну или несколько цифр.
Я обозначил такую предметную область. Запросы не меняются.
Я не собираюсь писать "Генератор, превращающий WebApi вашей еле работающей СЭД в Амазон".
Нет, об этом написано в первой статье. Вы их читаете или сразу приходите что-то обьяснять? Может, вы даже не понимаете ООП.
Тут по описанию предметной области такой переход не возможен (только расширение API, суровый IOT).
В СЭД: Это аномальное явление - если меняю инфраструктуру переписываю генераторы инфраструктуры.
В первой статье написано - есть бизнесы у которых прямо специфические запросы приходят, и их много, и их надо в базу писать.
Прямо с завода пришли и говорят - наши вендинги вот так аналитику отсылают.
Это - доменная область? (предметная)
Да.
Это похоже на ORM - нет.
Из-за плохого понимания границ DDD и возникает куча вопросов.
А в ORM что?
1) У нас вот такие документы и поля
2) А по состоянию они вот так передвигаются.
3) А вот при таком переходе еще и интеграция отрабатывает
О, привычные объекты.
Да, причем к абсолютному
Иногда я захожу на хаб PHP и спорю там.DDD как расшифровывается?
Domain-Driven Design
С вики
Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. domain-driven design, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей.
У нас предметная область какая?
Запросы - Вот мы и создали объекты для описания HTTP запросов в Domain.
Далее, на основе описания нашей пока скудной предметной области при помощи генераторов пишем весь Boilerplate (контроллеры в Infrastructure, воркеры в Application, DTO в Application).
Спорить с Вами дальше не буду - прошлый проект показывали даже ребятам из Росатома, сказали круто ).
Если будет время - напишу цикл по BoilerTemplate своими руками (прямо с обьектами ORM и flow в домене, чтобы даже плохо разбирающиеся в DDD люди понимали о чем речь).