Comments 8
Спасибо за интересную статью. Чуток покритикую :-) На мой взгляд структура выглядит слабо и не нормализовано. Это специально для статьи? Если да - то ок. А иначе, чуть разовью мысль. Если мы начинаем говорить про ddd и моделирование предметной области то надо четко отделять объекты от того как мы их видим.
Пример: Вам дали пачку денег и попросили составить реестр купюр. Вряд ли вы будете делать пометки прямо на банкнотах. Вы составите отдельный список. И будете в него записывать номера, номиналы и т.п. Если вас попросят рассортировать купюры по номиналу - то опять, сами купюры останутся неизменны - во просто положите их в разные кучки. И тут важно что кучка хранит в себе банкноту а не наоборот. С оборудованием тоже самое. Если вы описываете объект станок - то это объект сам по себе вес, производитель и т.п. А его включение в иерархии - это отдельно. Представьте, что у вас есть два абсолютно одинаковых станка. Тогда уместно хранить описание станка отельной таблицей. А экземпляры, где будет серийный номер, дата производства и т.п - отдельно. Если кто-то провидите ревизию станков - то это отдельный реестр кто, когда, состояние и т.п. Но сам Станок существует не зависимо от того есть о его учете запись в БД или нет.
И пара вопросов про детали:
Как поступаете если в объекте есть большой список? Грузите его всегда? Или делаете частично загруженные объекты? (How Incomplete DDD Aggregates Can Improve Application Performance )
Используете ли строго типизированные ID? (How Strongly Typed IDs Can Make Your Code More Expressive)
Спасибо за комментарий, очень рад, что статья показалась вам интересной)
Насчет структуры, похожая реализация у нас на данный момент. Вашу мысль я понял и соглашусь, что так было бы правильнее, думаю, в будущем учтем подобный подход. Без ошибок все-таки никуда, особенно в такой сложной теме:)
1. По-хорошему аггрегат должен доставаться полностью из базы. У нас есть разделение на read и write операции. Если мы хотим просто вывести данные, то большие списки подгружаем по мере необходимости. У нас есть отдельные запросы на получение связанных сущностей. Например: грузим данные сущности Notification, если пользователю нужны связанные данные, то при переходе на вкладку отдельным запросом подгружаем уже списки. Если необходимо обновить сущность, то в таком случае вытаскиваем ее полностью и обновляем необходимые данные. Один аггрегат, одна транзакция.
2. Конкретно в этом продукте не использовали, так как на начальном этапе подумали, что это избыточно, но в следующих продуктах думаем попробовать их, так как в них тоже есть свое преимущество, как минимум строгая типизация)
Интересная мысль, что агрегат должен полностью извлекаться из бд. А какие ещё могут быть варианты? Часть агрегата брать в бд, а остальное откуда? Из другой бд? Из веб-сервиса??
А вы используете какой-то DDD+CRUD фреймворк или всё самописное?
Всё самописное
Вообще я даже не слышал про подобные фреймворки, если есть какие примеры, буду рад, если поделитесь
Платные я не изучал, а из бесплатных оперсорсных - ABP Framework, https://abp.io/
Как подружить DDD и Entity Framework Core?