Как узнать счета-фактуры проекта?
Вы написали:
Я думаю, что проект не должен иметь ссылку на идентификатор корня агрегата счета, потому что на самом деле счет-фактура не нужен для логики проектов, просто чтобы знать связь между ними.
Это совершенно верная точка зрения, которая также соответствует нормальному времени жизни этих объектов:
Сначала кто-то определяет некий проект, содержащий список сервисов. Эти сервисы составляют проект, поэтому они могут быть частью ограничивающего контекста проекта.
Если это платный проект, поставщик услуг создаст одно или несколько предложений для этих услуг. В зависимости от размера бизнеса для этих предложений может потребоваться формальный идентификатор или они могут содержать только дату и описание в текстовых формах о предлагаемых услугах.
Далее заказчик формирует заказ на предлагаемые услуги. Этот заказ обычно получает идентификатор, под которым персонал аккаунта может хранить и находить его. Он также будет иметь отношение к прежнему предложению - может быть, это ID, может быть, данный в текстовом виде (но если он будет просто в текстовом виде, то кто-то из поставщика услуг должен будет как-то связать заказ с услугой или проектом - на степень детализации, которую требует конкретный бизнес).
Позже, после оказания услуг, формируется счет со ссылкой на прежний заказ.
Обычно это происходит в нескольких компаниях, ориентированных на оказание услуг, поэтому существует эта цепочка
Проект - Услуги - Предложение - Заказ - Счет
с проектом в самом начале и счетом в дальнем конце.
Исходя из этого, при необходимости можно воссоздать проект, принадлежащий счету-фактуре. Однако какие из этих взаимосвязей вы действительно храните в своей системе в форме, которую может эффективно оценить не только человек, но и программа, — это другой вопрос! Это зависит не от того, какие отношения существуют в теории, а от того, какую обработку должна выполнять система.
Но я не уверен, что это правильно, и у меня могло быть такое отношение.
Это не неправильное, но не единственно правильное решение. Что вам нужно проанализировать, так это варианты использования / процессы / функции, которые вы хотите реализовать в программном обеспечении. Если у вас есть в основном варианты использования, которые выполняются в проектах/сервисах, а другие — для счетов, требующих только некоторого идентификатора проекта, но не функций из ограниченного контекста проекта, то имеет смысл дать каждому свой собственный BC.
Но если это решение правильное, то чтобы узнать, к какому проекту относится инвойс, нужно ли иметь ссылку на ID проекта?
Как я уже сказал, если вы храните такие идентификаторы, это полностью зависит от процессов, которые вы хотите реализовать.
Например, вы хотите предоставить такой вариант использования: «Выяснение, есть ли какие-либо неоплаченные счета для одного конкретного проекта». Если вы не хотите, чтобы кому-то приходилось использовать глобальный текстовый поиск для определения потенциальных счетов-фактур для конкретного проекта впоследствии (и после этого вручную просматривать некоторые отсканированные PDF-файлы), может быть хорошей идеей хранить счет-фактуру вместе с некоторой информацией. где он принадлежит всякий раз, когда он создается. Если вы храните идентификатор проекта внутри счета-фактуры, или идентификатор проекта вместе с номером услуги, или просто номер заказа (хотя заказ как-то связан с проектом) зависит от вас и, возможно, также зависит от того, как и кем кому эта информация и ссылки будут введены в вашу систему.
Короче говоря: вы не можете ответить на такие вопросы, просто взглянув на данные. Вам нужно подумать о процессах, которые вы хотите, чтобы система поддерживала, о поведении системы, о том, какие отношения должны быть выражены в машиночитаемой форме, а какие могут оставаться в ней свободно, не строго определенным образом. Также имеют значение цифры: если ваш бизнес выставляет один счет в год на каждого клиента за услугу, которая представляет собой весь проект, у вас будут другие требования, чем когда ваш бизнес выставляет 500 различных счетов в год на одного клиента для 50 различных проектов, где каждый проект состоит из десяток различных сервисов.
Прикрепляю к посту несколько видео по теме: