CQRS, DDDD в учетной области

Question

Мне интересно, как правильно моделировать мои агрегаты. Домен является бухгалтерским, и у меня есть три объекта: Account, AccountingEntry (это должен быть объект значения?) И AccountingTranscation. Счет может быть, скажем, банковский счет клиента. AccountingEntry - это запись в учетной записи, а AccountingTransaction связывает несколько записей, которые составляют одну транзакцию (например, перенос из учетной записи A в учетную запись B). все вместе.

Мое мышление состоит в том, чтобы смоделировать Account и AccountingTransaction как агрегаты, а AccountingEntry как коллекцию в AccountingTransaction. Это сделано для того, чтобы агрегат учетных транзакций принудительно применял инвариант, который говорит, что все записи в транзакции должны быть равны нулю. Записи будут содержать ссылку на идентификатор связанных с ними учетных записей (это будет полезно, если, скажем, мы хотим отменить транзакцию). Счета не будут содержать никаких ссылок на записи, но будут содержать баланс.

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

Я хотел бы знать, правильно ли я моделирую это.

Я также хотел бы знать, как обеспечить невозможность создания учетной записи, которая будет содержать ссылку (ID) на недействительную (несуществующую) учетную запись. Следует ли использовать учетную запись в качестве фабрики для создания записи, передавая свой собственный идентификатор?

Answer 1

Я думаю, что модель довольно хорошая. Вы можете использовать Транзакцию как фабрику Записи (используйте Учетную запись в качестве аргументов) в соответствии с Паттерном Учетной записи Мартина Фаулера.