Это конечно интересно всё и в целом вроде вполне логшично всё, но о каких задачах, которые вы решаете идёт речь? Позвольте пробежаться галопом по европам....
В статье вы описываете выбраные решения, но какую конкретно задачу вы решаете не описано? Нет деталей, откуда тогда появились решения? Например в тот момент, когда вы дошли до темы БД Вы сразу описываете решение выбрать СУБД и взаимодействоать с ней посредством определённо ORM. Ближе к концу статьи вообще разговор пошел о DDD. У меня сложилось ощущения вырваного текста из некой истории. Хотите облегчить жизнь архитекту? Подарите ему готовую документацию по новому проекту где уже (за него/неё) описаны все requirements, use cases и например волатильности как мимнимум. И вы будете приятно удивлены, увидев дикий восторг от того что было сэконмлено десятки а то и сотни часов митингов, встречь с клиентом или его представителями, анализа требований и хотелок и консультаций с бизнесс аналитиками. Если конечно у вас не простенький проект ))))) А вот разговор о СУБД и DDD это в самую последнюю очередь.
Как архитект вы сначала определяете "ЧТО" вы будете создавать, а только потом "КАК" вы это будете реализовывать. Потому что технические решения по использованию инструментов, фрэймворков и тем более их реализация с точки зрения архитектуры это zero value activity. По этому я и пишу что не ясно что именно вы создаёте чтобы точно сказать, что описаные Вами сценарии и решения действительно облегчают жизнь архитектору а не наоборот.
Это конечно интересно всё и в целом вроде вполне логшично всё, но о каких задачах, которые вы решаете идёт речь? Позвольте пробежаться галопом по европам....
В статье вы описываете выбраные решения, но какую конкретно задачу вы решаете не описано? Нет деталей, откуда тогда появились решения? Например в тот момент, когда вы дошли до темы БД Вы сразу описываете решение выбрать СУБД и взаимодействоать с ней посредством определённо ORM. Ближе к концу статьи вообще разговор пошел о DDD. У меня сложилось ощущения вырваного текста из некой истории.
Хотите облегчить жизнь архитекту? Подарите ему готовую документацию по новому проекту где уже (за него/неё) описаны все requirements, use cases и например волатильности как мимнимум. И вы будете приятно удивлены, увидев дикий восторг от того что было сэконмлено десятки а то и сотни часов митингов, встречь с клиентом или его представителями, анализа требований и хотелок и консультаций с бизнесс аналитиками. Если конечно у вас не простенький проект )))))
А вот разговор о СУБД и DDD это в самую последнюю очередь.
Как архитект вы сначала определяете "ЧТО" вы будете создавать, а только потом "КАК" вы это будете реализовывать. Потому что технические решения по использованию инструментов, фрэймворков и тем более их реализация с точки зрения архитектуры это zero value activity.
По этому я и пишу что не ясно что именно вы создаёте чтобы точно сказать, что описаные Вами сценарии и решения действительно облегчают жизнь архитектору а не наоборот.