28 сентября 2016 г.
Речь идет о моделировании домена, отражающего намерения бизнеса, без сложности технических решений.
DDD — это не только то, как писать или реализовывать и использовать шаблоны проектирования в вашем коде, это больше решение проблемы предметной области в явном смысле, которое все заинтересованные стороны могут понять и обсудить.
Пример. Оба этих кода взяты из проекта, над которым я работаю. Это один и тот же проект, только первый использует PHP, а второй — TypeScript/JavaScript. (игнорировать разницу в синтаксисе)
Проект предоставляет API, с помощью которого клиенты могут отправлять произвольный код для компиляции в изолированной среде.
Глядя между этими двумя, какой из них, по вашему мнению, имеет больше смысла?
Последний использует DDD для уточнения решения предметной области.
Мне потребовался почти день, чтобы выяснить правильный интерфейс API/название для проблемы, но это того стоило, так как теперь у меня есть модель, которую могут легко понять все заинтересованные стороны.
Я рекомендую вам уделить такое внимание и энергию только важным поддоменам, поскольку моделирование может быть очень сложным и трудоемким процессом.
В конце концов, этот код может быть легко обсужден или понят другими участниками проекта — вашей командой, новыми программистами в команде, QA, техническим писателем, вашим начальником и т. д.
Гораздо проще обсудить «Компилятор должен работать в изолированной среде», чем «Песочнице нужна песочница».
Это все на данный момент.
