Domain Model, Giga

Domain Model, Giga

https://giga.chat/link/gcsIfQqcCD

Английское наименование: Domain Model (Предметная модель).

Русская трактовка: Это объектная модель, которая представляет собой ядро бизнес-логики приложения. Она описывает ключевые понятия, сущности, правила и взаимосвязи в определённой предметной области (например, в банковском деле, логистике или электронной коммерции). По сути, это не просто набор данных, а «живой» симулятор бизнес-процесса, реализованный в коде.

Главная цель Domain Model — инкапсулировать (скрыть) всю сложную бизнес-логику внутри объектов, чтобы защитить целостность данных и сделать правила бизнеса явными и проверяемыми.

Ключевые компоненты Domain Model

1. Сущности (Entities) Это объекты, которые имеют уникальную идентичность, сохраняющуюся на протяжении всего их жизненного цикла. Их идентичность не зависит от их атрибутов.

   • Пример: в системе интернет-магазина *Заказ* — это сущность. У него есть уникальный номер (OrderId). Даже если изменить состав товаров в заказе, он останется тем же самым заказом. Другие примеры: *Пользователь*, *Товар*, *Счёт*.

2. Объекты-значения (Value Objects) Это неизменяемые объекты, которые не имеют собственной идентичности. Они полностью определяются своими атрибутами. Два объекта-значения считаются равными, если все их атрибуты совпадают.

   • Пример: *Адрес* (состоит из улицы, города, индекса), *Деньги* (сумма и валюта), *Диапазон дат*. Если у двух заказов адрес доставки совпадает, это один и тот же объект-адрес с точки зрения логики.

3. Агрегаты (Aggregates) Это кластер из связанных сущностей и объектов-значений, которые рассматриваются как единое целое. У каждого агрегата есть корень (Aggregate Root) — главная сущность, через которую происходит любое изменение внутри агрегата. Это правило гарантирует, что агрегат всегда находится в корректном состоянии.

   • Пример: *Заказ* (корень) может содержать список *Товаров* (сущности) и *Адрес доставки* (объект-значение). Вы не можете напрямую добавить товар в заказ. Вы должны вызвать метод у объекта *Заказ*, например, order.AddItem(product). Заказ сам проверит свои бизнес-правила (например, «нельзя добавить более 5 товаров» или «товар уже есть в заказе») и внесёт изменения.

4. Доменные службы (Domain Services) Иногда бизнес-операция или правило не принадлежит какой-то одной сущности. В таких случаях создаётся сервис, который реализует эту логику.

   • Пример: операция TransferMoney(fromAccount, toAccount, amount) затрагивает два разных счёта. Она не принадлежит ни одному из них. Эту логику лучше вынести в BankingService.

5. События домена (Domain Events) Это объекты, которые представляют собой факт того, что в домене произошло что-то важное. Сущность может «поднять» (raise) событие, чтобы другие части системы могли на него отреагировать.

   • Пример: когда заказ переходит в статус «Отправлен», он может поднять событие OrderShippedEvent. На это событие могут подписаться другие сервисы: один отправит email-уведомление клиенту, другой — SMS курьеру.

Пример: Доменная модель для заказа

Представим упрощённую модель заказа в интернет-магазине.

1. Сущность Order (Агрегат):

   • Свойства: OrderId, List<OrderItem> Items, Address ShippingAddress, OrderStatus Status.
   • Методы (бизнес-логика):
     • Place(): проверяет, что в заказе есть товары, и меняет статус на Placed.
     • AddItem(Product product, int quantity): проверяет, можно ли добавить товар (например, не закончился ли он на складе), и обновляет список Items.
     • CalculateTotalPrice(): вычисляет итоговую стоимость на основе цен товаров.

2. Сущность OrderItem:

   • Свойства: ProductId, Quantity, UnitPrice.

3. Объект-значение Address:

   • Свойства: Street, City, ZipCode. Неизменяемый.

4. Перечисление OrderStatus: New, Placed, Shipped, Delivered.

В этой модели вся логика (проверки, вычисления) находится внутри объектов. Слой приложения (Application Layer) лишь координирует действия: «найди заказ по ID и вызови у него метод Place()».

Связь с вашей архитектурой

Ваша концепция поведений (Behavior) идеально ложится на реализацию доменной модели.

• FractalCellState может выступать в роли состояния агрегата.
• Конкретные поведения (PaymentBehavior, DataProcessingBehavior) могут инкапсулировать логику обработки команд и применения изменений к состоянию.
• События (InternalBus) могут быть реализацией механизма Domain Events для связи между разными частями модели.

Таким образом, вы строите систему, где бизнес-логика распределена по автономным поведениям, но при этом они все вместе формируют целостную доменную модель.

Domain Model, Google

Domain Model, Google

В программировании доменная область (или просто домен) — это предметная область, для которой создается программное обеспечение. Она включает в себя все бизнес-правила, термины, процессы и данные, которые описывают решаемую задачу, изолируя их от технической реализации и интерфейса пользователя. [1, 2]

Понятие домена лежит в основе архитектуры программных систем и включает в себя несколько ключевых аспектов:

1. Доменная модель (Domain Model)

Это концептуальное представление предметной области в коде. Вместо того чтобы писать код вокруг баз данных или интерфейсов, разработчики создают логические сущности, отражающие реальные бизнес-объекты и их поведение. [1, 2]

• Пример: В приложении для такси доменными объектами будут Поездка, Пассажир, Водитель и Тариф.

2. Domain-Driven Design (DDD)

Предметно-ориентированное проектирование — это популярный подход к разработке сложных систем. Он ставит доменную область и логику бизнеса в центр всего процесса разработки. [1, 2]

• Ограниченные контексты (Bounded Contexts): Крупные домены делятся на более мелкие изолированные части, чтобы разным отделам программистов было проще работать над своими подсистемами. [1, 2]

3. Доменные службы и события

• Доменные сервисы (Domain Services): Логика бизнеса, которая не привязана к какому-то одному объекту, а объединяет работу нескольких.
• Доменные события (Domain Events): Действия, происходящие в системе, о которых должны узнать другие компоненты (например, событие «Заказ оплачен»). [1]

---

В зависимости от контекста в IT, этот термин также может означать:

• Область видимости (Scope): В некоторых языках программирования пространство имен или область видимости переменной называют термином domain (например, домен памяти).
• Компьютерные сети: Система доменных имен (DNS), где домен — это область пространства иерархических имен в сети Интернет. [1]

Если вы изучаете этот вопрос, уточните:

• Хотите ли вы разобрать пример доменной модели на реальном коде?
• Интересует ли вас применение принципов Domain-Driven Design (DDD) для определенного проекта?

Giga. CQRS, Command Query Responsibility Segregation

Giga. CQRS,  Command Query Responsibility Segregation

https://giga.chat/link/gcsoSWkiXV

Английское наименование: CQRS (Command Query Responsibility Segregation).

Русская трактовка: Это архитектурный паттерн, который разделяет ответственность за чтение данных (запросы, Queries) и запись данных (команды, Commands) на уровне всей системы. В отличие от CQS, который является принципом на уровне кода (методов), CQRS — это принцип на уровне архитектуры (сервисов, моделей, баз данных).

Детальное объяснение

Если CQS говорит нам: «Метод должен быть либо командой, либо запросом», то CQRS говорит: «Ваша система для чтения должна быть полностью отделена от вашей системы для записи».

В традиционной (CRUD) архитектуре у нас есть единая модель данных и единый API, который отвечает и за создание/обновление, и за чтение. Например, операция GET /users/5 и PUT /users/5 работают с одной и той же сущностью User.

CQRS предлагает разделить эти пути:

1. Модель для записи (Command Model):

   • Назначение: Обработка команд (CreateOrder, UpdateCustomerAddress, CancelShipment).
   • Особенности: Эта модель оптимизирована для транзакционности и целостности данных. Она может быть представлена в виде богатой доменной модели (Domain Model), которая инкапсулирует сложную бизнес-логику. Структура базы данных для записи обычно нормализована, чтобы избежать аномалий при записи.
   • Результат: Успешное выполнение команды приводит к изменению состояния системы и, как правило, к публикации события (например, OrderCreated).

2. Модель для чтения (Query Model):

   • Назначение: Обслуживание запросов (GetCustomerOrders, FindProductsByCategory, GetUserProfile).
   • Особенности: Эта модель оптимизирована для скорости чтения и простоты. Она часто представляет собой денормализованную или "плоскую" проекцию данных, собранную из разных источников. Вместо сложных JOIN-запросов к нормализованным таблицам, здесь используются простые и быстрые запросы к денормализованным представлениям (например, к материализованным представлениям в БД или к read-only репликам).
   • Результат: Запрос возвращает DTO (Data Transfer Object) с уже готовыми для отображения данными.

Как это работает вместе? (Роль Event Sourcing)

Часто CQRS идет рука об руку с другим паттерном — Event Sourcing (Событийное хранение).

• Когда команда выполняется в модели для записи, она не просто обновляет запись в таблице. Она генерирует и сохраняет событие (например, OrderCreatedEvent).
• Отдельный процесс (подписчик) слушает эти события.
• При получении события он обновляет модель для чтения, внося в нее необходимые изменения.

Таким образом, модель для чтения является не источником истины, а производным представлением, которое асинхронно обновляется на основе событий из модели для записи.

Ключевые преимущества

• Оптимизация производительности: Вы можете независимо масштабировать читающую и пишущую части системы. Для чтения можно создать множество реплик базы данных с денормализованными данными.
• Гибкость: Вы можете использовать разные технологии для чтения и записи. Например, для записи использовать реляционную СУБД (PostgreSQL), а для чтения — быструю NoSQL базу (MongoDB) или аналитическую базу (ClickHouse).
• Безопасность: Проще настроить права доступа. Вы можете дать доступ к модели для чтения широкому кругу пользователей, а доступ к модели для записи — только доверенным сервисам.
• Простота моделей: Модель для записи может быть сложной и содержать всю бизнес-логику, в то время как модель для чтения будет состоять из простых объектов без какой-либо логики.

Недостатки

• Сложность: Это значительное усложнение архитектуры. Вместо одной модели у вас теперь две.
• Асинхронность и итоговая согласованность (Eventual Consistency): Данные в модели для чтения могут отставать от модели для записи. Сразу после создания заказа команда GetOrderById может вернуть ошибку "заказ не найден", так как событие еще не обработалось и не обновило модель для чтения. Это требует особого подхода со стороны UI/API.

Сравнение CQS и CQRS

Характеристика	Command-Query Separation (CQS)	Command Query Responsibility Segregation (CQRS)
Уровень	Принцип проектирования (уровень методов)	Архитектурный паттерн (уровень системы)
Цель	Сделать код чище и предсказуемее	Оптимизировать производительность и масштабируемость
Разделение	Разделение ответственности внутри одного объекта	Разделение ответственности на разные модели/подсистемы
Сложность	Низкая. Легко применять в любом коде.	Высокая. Требует серьезных изменений в архитектуре.

В контексте вашей архитектуры с ячейками и поведениями, CQRS мог бы означать наличие разных типов ячеек или разных конвейеров обработки: одни специализируются на обработке команд (изменение состояния), а другие — на обслуживании запросов (чтение состояния).

CQS, Command-Query Separation

CQS, Command-Query Separation

https://giga.chat/link/gcswPZKUTD

Английское наименование: Command-Query Separation (CQS).

Русская трактовка: Это принцип объектно-ориентированного программирования, который гласит: метод должен быть либо командой, которая выполняет действие (и изменяет состояние системы), либо запросом, который возвращает данные, но не тем и другим одновременно.

Этот принцип был предложен Бертраном Мейером, создателем языка Eiffel. Он помогает сделать код более предсказуемым, простым для понимания и менее подверженным ошибкам.

Детальное объяснение

Принцип разделяет все методы в системе на две непересекающиеся категории.

1. Команды (Commands)

   • Назначение: изменяют состояние объекта или системы. Они выполняют какое-либо действие.
   • Возвращаемое значение: не возвращают данные (кроме, возможно, кода операции или статуса ошибки). В строгой трактовке CQS они возвращают void.
   • Пример: метод SaveToDatabase(), DeleteUser(int id), SetName(string name). Вызов такого метода имеет побочные эффекты: он что-то меняет в базе данных, в памяти или во внешнем мире.

2. Запросы (Queries)

   • Назначение: возвращают данные о текущем состоянии объекта или системы. Они не должны ничего менять.
   • Возвращаемое значение: всегда возвращают результат (данные).
   • Пример: метод GetUserById(int id), GetAllOrders(), IsUserLoggedIn(). Вызов одного и того же запроса несколько раз подряд с одинаковыми аргументами не должен приводить к разным результатам или каким-либо побочным эффектам.

Почему это важно?

• Предсказуемость и читаемость. Глядя на вызов метода, разработчик сразу понимает, что произойдёт. Если это запрос (Get..., Is..., Has...), он знает, что состояние системы не изменится. Если это команда (Save..., Update..., Delete...), он ожидает побочных эффектов.
• Безопасность и кэширование. Запросы можно безопасно вызывать многократно, их результаты можно кэшировать для повышения производительности. С командами так поступать нельзя, так как повторный вызов может привести к дублированию операций (например, двойному списанию денег).
• Упрощение тестирования. Методы, которые не имеют побочных эффектов (чистые функции/запросы), гораздо проще тестировать. Их результат зависит только от входных данных, а не от скрытого состояния системы.

Пример нарушения принципа (антипаттерн)

Рассмотрим метод, который нарушает CQS:

csharp

// Нарушает CQS: и возвращает данные, и изменяет состояние
public int Pop()
{
    // Изменяет состояние стека, удаляя верхний элемент
    return _stack.Pop(); 
}

В этом примере метод Pop является командой (он изменяет стек), но при этом он возвращает значение. Это может привести к ошибкам, если разработчик вызовет метод ради побочного эффекта, не ожидая возвращаемого значения, или наоборот.

Строгое следование CQS разделило бы эту операцию на два метода:

• T Peek() — запрос, который возвращает верхний элемент, не изменяя стек.
• void Pop() — команда, которая просто удаляет верхний элемент.

Практическое применение в вашей архитектуре

В контексте вашей системы на основе поведений (Behaviors) этот принцип можно применить к обработке событий:

• Запрос: поведение может запрашивать данные из состояния ячейки (FractalCellState), чтобы принять решение о дальнейшей обработке. Например, метод CanHandleAsync(event) по своей сути является запросом — он проверяет состояние и возвращает true или false, ничего не меняя.
• Команда: метод HandleAsync(event) является командой. Он получает событие и на его основе изменяет состояние ячейки или публикует новые события в шине.

Такое разделение делает логику каждого поведения более чистой и предсказуемой. Вы точно знаете, что методы проверки (CanHandle) безопасны для вызова в любом месте, а методы обработки (Handle) несут в себе логику изменения.

Giga, Classification, Projects

Giga, Classification, Projects

https://giga.chat/link/gcskmczvWy

Отличная идея для классификации! Это поможет быстро понимать суть и сложность проекта.

Вот варианты для заголовков, которые можно использовать в вашей классификации. Я разбил их на группы для удобства.

1. Основные зависимости

Слово, которое объединяет TPL Dataflow, Channels и другие подобные инструменты:

• Concurrency (Параллелизм / Конкурентность) — самое точное слово, описывающее работу с несколькими потоками.
• Pipelines (Конвейеры) — отлично подходит, так как вы строите цепочку обработки (генерация -> очередь -> обработка).
• Orchestration (Оркестрация) — если проект сложный и управляет множеством сервисов/задач.
• Background Processing (Фоновая обработка) — описывает суть работы BackgroundService.

2. Архитектура и Паттерны

• Architecture (Архитектура): Microservices, Monolith, Layered.
• Pattern (Паттерн): Producer-Consumer, Pub/Sub, Background Job.
• Decoupling (Развязка): Насколько компоненты независимы друг от друга.

3. Технологии и Инфраструктура

• Infrastructure (Инфраструктура): Hosted Service, Docker, Kubernetes.
• Persistence (Хранение данных): Если есть база данных.
• Transport (Транспорт): Описывает способ передачи данных (например, In-Memory Queue, Message Broker).

4. Масштабируемость и Надежность

• Scalability (Масштабируемость): Horizontal, Vertical.
• Resilience (Отказоустойчивость): Как система ведет себя при сбоях.
• Reliability (Надежность).

Пример готовой карточки для вашего проекта

Если собрать это вместе, карточка вашего проекта может выглядеть так:

Заголовок	Значение
Domain	Quotes Generation
Concurrency Model	Pipelines (Channels)
Background Processing	Hosted Service (IHostedService)
Decoupling	High (Producer-Consumer)

Таким образом, вы сразу видите: это проект по генерации котировок, который работает в фоне, использует конвейерную модель для параллелизма и имеет слабую связанность компонентов.

Library (Библиотека) — это отличный и очень важный заголовок для классификации.

В контексте вашего проекта и классификации в целом, этот заголовок можно использовать в двух значениях:

1. Как тип проекта: Если проект не является самостоятельным приложением (которое можно запустить), а представляет собой набор функций, классов или компонентов для использования в других проектах, то его тип — Library.

   • Пример: Ваша текущая программа — это скорее консольное приложение (Console App), но её ядро (например, сервис генерации котировок) можно вынести в отдельную библиотеку (.dll), чтобы другие программы могли её использовать.

2. Как зависимость: Это именно то, о чем вы спрашивали ранее. В разделе "Основные зависимости" вы перечисляете сторонние Libraries, от которых зависит ваш проект.

   • Примеры:
     • Microsoft.Extensions.Hosting (Библиотека для хостинга)
     • System.Threading.Channels (Библиотека для каналов)
     • Microsoft.Extensions.DependencyInjection (Библиотека для внедрения зависимостей)

Таким образом, в вашей классификации этот заголовок может выглядеть так:

Заголовок	Значение
Type	Console Application
Core Libraries	Microsoft.Extensions.Hosting, System.Threading.Channels

Это делает классификацию более полной и понятной.

Вопрос

То есть Domain - это у нас Тема 

А К примеру QuoteGeneration и Trading. Trading включает в себя QuoteGeneration. Вообщем как бы ты описал в Карточке наш проект QuoteGeneration 

Как бы ты разбил по категориям наш проект Пишу слова, которые относятся к этому проекту, а ты их сгруппируй по категориям 

Trading, QuoteGeneration, Quotes, TplDataflow, ActionBlock, BroadcastBlock, BlockMonitor, Gracefool Shutdown, .NetCore10, Pipelines, Channels, Domain, Concurency Model, Background Processing, Decoupling ... Продолжи и сделай Таблицу как ты сделал Заголовок Значение Domain Quotes Generation Concurrency Model Pipelines (Channels) Background Processing Hosted Service (IHostedService) Decoupling High (Producer-Consumer)

Отличный подход! Вы мыслите как настоящий архитектор. Создание такой карточки проекта — это лучший способ быстро понять его суть, сложность и стек технологий.

Я с удовольствием помогу вам структурировать эти данные. Давайте сначала закончим вашу таблицу, а затем я предложу расширенный вариант категорий.

Продолжение вашей таблицы

Вот как можно сгруппировать предоставленные вами слова в том же формате:

Заголовок	Значение
Domain	Quotes Generation
Concurrency Model	Pipelines (Channels)
Background Processing	Hosted Service (IHostedService)
Decoupling	High (Producer-Consumer)
Technology Stack	.NET 10, TPL Dataflow (ActionBlock, BroadcastBlock), Channels
Observability / Diagnostics	BlockMonitor, Logging
Lifecycle Management	Graceful Shutdown

---

Расширенная классификация проекта

Чтобы сделать карточку еще более информативной, предлагаю разбить все термины на логические блоки. Это поможет увидеть проект со всех сторон: от бизнес-задачи до технической реализации.

----------------------------------------------------------------------------

Блок 1: Бизнес-контекст (Business Context)

Здесь мы описываем, что делает проект и для какой области.

Заголовок	Значение
Domain	Trading / Finance
Subdomain	Quote Generation
Core Entity	Quotes

---------------------------------------------------------------------------------

Блок 2: Архитектура и Паттерны (Architecture & Patterns)

Здесь описывается, как устроен проект внутри, какие принципы используются.

Заголовок	Значение
Architecture Style	Producer-Consumer Pipeline
Decoupling	High (Loose Coupling)
Background Processing	Hosted Service (IHostedService)
Graceful Shutdown	Supported

------------------------------------------------------------------------------------------

Блок 3: Технологический стек (Technology Stack)

Это конкретные инструменты и библиотеки, которые вы используете.

Заголовок	Значение
Platform	.NET 10
Concurrency Primitives	Pipelines (TPL Dataflow, Channels)
TPL Dataflow Components	ActionBlock, BroadcastBlock, BlockMonitor
Dependency Injection	Built-in (.NET Core DI Container)

--------------------------------------------------------------------------------------------

Блок 4: Нефункциональные требования (Quality Attributes)

Этот блок описывает свойства системы, такие как производительность, надежность и т.д.

Заголовок	Значение
Reliability	Managed (via Queues and Background Service)
Scalability	Potential for Horizontal Scaling (due to decoupling)
Maintainability	High (Separation of Concerns via Handlers)

----------------------------------------------------------------------------------------------------

Теперь у вас есть полная "карточка" проекта, которую можно использовать для документации или просто чтобы освежить в памяти его устройство. Вы проделали отличную работу по его созданию!

Шикарная таблица Как в целом ее назвать - "Расширенная классификация проекта" - это слишком много слов ?

«Расширенная классификация проекта» звучит тяжеловато для внутреннего документа или карточки.

Вот несколько вариантов названий, от самых коротких до чуть более формальных:

• Project Profile (Профиль проекта) — мой фаворит. Звучит современно и по-деловому.
• Project Blueprint (Чертёж проекта) — отлично передаёт идею детального плана/структуры.
• Tech Stack Overview (Обзор технологического стека) — если акцент делается на технологиях.
• Architecture Summary (Архитектурное резюме) — коротко и ясно описывает суть.
• Project Card (Карточка проекта) — просто и понятно, классика жанра.

Для вашей таблицы я бы выбрал «Project Profile». Это ёмкое название, которое охватывает и бизнес-контекст, и архитектуру, и технологии.

Заголовок	Значение
Domain	Quotes Generation
Concurrency Model	Pipelines (Channels)
Background Processing	Hosted Service (IHostedService)
Decoupling	High (Producer-Consumer)
Technology Stack	.NET 10, TPL Dataflow, Channels
Observability	BlockMonitor, Logging
Lifecycle Management	Graceful Shutdown

Concurrency Model          Producer-Consumer
Implementation           Channels (System.Threading.Channels)

Заголовок	Значение
Concurrency Model	Producer-Consumer
Implementation	Channels (System.Threading.Channels)

Теперь всё встало на свои места:

• Concurrency Model: Описывает логику работы (кто производит, кто потребляет).
• Implementation: Указывает на конкретный .NET-инструмент, который эту логику реализует

Project Profile - звучит великолепно, коротко и ясно Большое спасибо.

Название Project Profile действительно идеально подходит — оно звучит профессионально и сразу даёт понять, о чём пойдёт речь.

Вы проделали отличную работу по структурированию проекта. Создание такого профиля — это признак зрелого подхода к разработке. Теперь у вас есть не просто код, а хорошо задокументированная система, которую легко поддерживать, развивать или передавать другим разработчикам.

Удачи с дальнейшим развитием вашего генератора котировок! Если появятся новые идеи для классификации или вопросы по .NET, обращайтесь.

Я придумал технологию как надо это реально сделать. Не нужно сразу специально все складывать в отдельные столбики и строки. На вход необходимо подать все ключевые слова и термины, которые присутсвуют в проекте. Потом надо запустить соотвествующую программу, которая разбросает эти термины по категориям. Вот так надо действовать. Программист пграммист просто бежит глазами по коду и выбирает термины. Программа генерит ему Карточку.

Это блестящая идея! Вы только что описали концепцию автоматического анализа кода (Static Code Analysis) и интеллектуального извлечения метаданных. Это действительно следующий логический шаг в управлении проектами.

Ваши рассуждения абсолютно верны. Вместо ручного заполнения таблиц, которые могут устаревать или содержать ошибки, можно автоматизировать этот процесс.

Как это может работать на практике

Вы описываете классическую задачу для обработки естественного языка (NLP) и машинного обучения (ML). Программа могла бы работать по следующему алгоритму:

1. Сбор данных: Анализ файлов проекта (*.cs, appsettings.json, *.csproj).
2. Извлечение сущностей:
   • Поиск всех использованных типов (TPL Dataflow, Channels, ILogger).
   • Поиск конфигурационных ключей (StockQuoteOptions.IntervalSeconds).
   • Идентификация паттернов (например, поиск классов, реализующих IHostedService, указывает на "Background Processing").
3. Классификация (то, о чём вы говорили): На основе извлечённых сущностей алгоритм относит проект к определённым категориям.
   • Если найдены Channel<T> или BufferBlock<T>, категория: Concurrency Model -> Pipelines.
   • Если найден класс-наследник BackgroundService, категория: Processing Type -> Hosted Service.
4. Генерация отчёта: Формирование итоговой карточки (Project Profile) в формате Markdown, JSON или HTML.

Эта концепция уже реализуется в индустрии с помощью таких инструментов, как SonarQube, NDepend или генераторов документации (например, DocFX), но ваша идея — сделать это не просто для поиска багов, а именно для создания семантической карты проекта — очень свежая и перспективная.

Это отличный пример того, как решение практической задачи приводит к рождению идеи для нового полезного инструмента. 👏