Я пытаюсь смоделировать свой домен на основе существующей системы на основе C # WinForm, которую я сделал, чтобы улучшить свое обучение DDD, поэтому я собрал гипотетическую концептуальную модель, чтобы упростить задачу. Сама система не имела типичного бизнес-домена с большим количеством логики, смешанной с объектами Entity Framework, которые использовались во всех аспектах системы. Я чувствую, что это был Большой шар грязи (BBOM).
Я работал над некоторыми концепциями DDD на работе, но я хочу улучшить свое общее понимание. Я прочитал Голубую книгу Эванса «Доменно-ориентированный дизайн: преодоление сложности в основе программного обеспечения» и Скотта Миллетса «Паттерны, принципы и практики предметно-ориентированного дизайна». Помимо просмотра бесчисленных видео по этой теме, а также статей Вона Вернона. Я чувствую, что за прошедшие годы я сделал больше разработок, основанных на данных, и для этого требуется возраст.
Таким образом, гипотетическая система - это система строгого контроля качества строительных продуктов, которая примерно соответствует моей системе.
Вот концептуальная модель:
Теперь я вижу три части этого - не обязательно ограниченные контексты, но я изо всех сил пытаюсь определить, где лежат эти ограниченные контексты.
Бизнес-процесс состоит из 3 частей:
- Определение продуктов
Для этого «пользователь» вводит различную информацию о продукте, включая название. В рамках этого они определяют, какой толщины должно быть изделие и из какого материала оно изготовлено. Они также определят, какой процесс необходимо использовать Builder для создания продукта. Они также определяют, требуется ли визуальный осмотр и проверка качества.
- Создать продукт
В рамках процесса «строитель» соберет изделие. Но это касается исключительно квалификации строителя. Строитель квалифицируется в отношении процесса, основанного на диапазоне толщины и материала, поэтому бизнес-правило разрешает выбирать строителя только в том случае, если он соответствует требованиям к толщине продукта, находящейся между диапазоном толщины процесса и материалом.
- Осмотр
После того, как Продукт построен, его можно осмотреть. В рамках этого, в зависимости от того, требуется ли визуальный контроль или проверка качества, обновленный квалифицированный «инспектор» сможет осмотреть Продукт. Они либо пройдут, либо не пройдут проверку.
В рамках этих процессов статус продукта будет обновляться. Это будет:
- Не собран
- Собранный
- Частично проинспектирован (одна из двух инспекций выполнена)
- Пройдена проверка (все проверки выполнены)
- Неудачная проверка (неудачная проверка)
Ниже приводится некоторая информация о системе за пределами домена, о которой нужно подумать:
- Система разработана так, чтобы быть многопользовательской, в которой можно одновременно вводить проверки.
- Возможно, что данные о продукте были введены неверно, что может быть исправлено, что может сделать недействительными любые введенные данные сборки и проверки.
- Введенные данные затем используются в различных отчетах.
Итак, мне нужны идеи относительно:
- Где лежат мои ограниченные контексты.
Как смоделировать мои агрегированные корни - какие данные должны быть корнем и какие объекты / объекты значений я должен включить.
Включаю ли я данные только тех объектов домена, которые мне нужны, в ограниченный контекст, т.е. не гидратирую объекты домена полностью.
Как реализовать что-то для расчета статусов через различные части процесса.
- Как обрабатывать случаи, когда данные могут быть введены неправильно, чтобы данные домена оставались правильными.
Меня не интересует какая-либо реализация репозитория, только концепции чистой предметной области, хотя мне может помочь вопрос, что мы должны сохранять для каждого ограниченного контекста.
У меня есть опасения, что несколько пользователей вводят данные, чтобы обеспечить единообразие данных о статусе продукта.
