Гексагональная архитектура и DDD на опыте интернет-магазина Спортмастер. Как дела с кодом?

[gandjustas]

А можно увидеть диаграмму последовательности вызовов "как было" и "как стало"? А что из обрывков кода на скрине категорически неясно что же поменялось.

[ezhov-da]

Последовательность вызовов, если мы говорим о "Controller -> Service -> Repository" не претерпела кардинальных изменений. Основные изменения были сделаны в архитектуре проекта, которые описываются в части 2 данного цикла статей, а так же изменения обязанности классов и их конструирования (пример с валидацией). Данная часть отражает наложение тактических шаблонов DDD на наш код и описывает ответственность за работу с ошибками в каждом контексте.

[gandjustas]

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

[dopusteam]

А в чем плюс приватного конструктора и фабричного метода, вместо просто конструктора с проверками внутри?

Ага, понял, возможность вернуть неуспешный результат?

[ezhov-da]

Ага, понял, возможность вернуть неуспешный результат?

Да, это один из плюсов. Достаточно подробно плюсы этого подхода описываются в книге "Effective Java" Блоха.

На вскидку могу вспомнить:

1. Возможность описания в контракте негативного результата

2. Возможность детального и понятного наименования метода

3. Возможность соблюдения инвариантов

[dopusteam]

Ну инварианты и в конструкторе можно (и нужно) соблюдать, не уверен, что это особенность именно статического.

А вот возможность потенциально создать несколько статических конструкторов с понятными названиями - звучит интересно.