🧩 А что такое домен, простите?
Я тут вернулась после 2х недель командировок, конференций и мини-отпуска и пока меня окунает в омут всего скопившегося. И немножечко меня окунуло в DDD.
DDD — вроде бы про язык. Про общее понимание между бизнесом и разработкой. Про то, чтобы сложное стало чуть понятнее. А теперь откройте любую из «каноничных» книг по DDD. Хотите у Эванса, хотите у Вернона. Хотите даже у Хононова. А теперь найдите там внятное определение домена. 🙃
Сюрприз: его там… нет. Есть
И есть «реальность бизнеса». Есть «область, где компания зарабатывает деньги». И вроде бы звучит хорошо — но когда ты на митапе или на курсе начинаешь объяснять, «что такое домен», и люди в зуме кивают, а потом кто-то говорит, что у него домен — это API, ты понимаешь, что все не так просто.
Когда-то я села и попыталась сформулировать определение для себя. Чтобы не спорить бесконечно. Чтобы использовать на мастер-классах, митапах и т.п.. И вот что у меня получилось:
Звучит сухо, но очень помогает. Вот убрать «платежи» — и остальное работает, просто не зарабатывает. А вот убрать «логистику» — и часть бизнеса встанет, но остальное будет жить. Значит, это отдельные домены. А вот «авторизация» — это не бизнес-домен, а скорее техническая компонента, обвязка.
Важно: я не настаиваю, что это единственное правильное определение. Но пока — это единственное, которое мне действительно помогает дизайнить архитектуру и язык.
С ним можно обсуждать приоритеты. Можно находить ядро. Можно на пальцах объяснить, почему часть системы — это не просто модуль, а именно бизнес-домен со своей логикой и ценностью.
Хотя термин «домен» в контексте DDD порой размытый, важно явно договариваться о его значении в каждом конкретном случае. Авторы основных книг по DDD – Эванс, Вернон, Хононов – закладывают понимание домена как предметной области бизнеса, но уровень этой области может различаться (весь бизнес vs. отдельная функция). Если мы уточним, что домен – это обособленная часть бизнеса с самостоятельной ценностью, то получим более четкую основу для стратегического дизайна.
💬 А вы как определяете «домен» в своей работе? И как объясняете это команде?
#architecture
Я тут вернулась после 2х недель командировок, конференций и мини-отпуска и пока меня окунает в омут всего скопившегося. И немножечко меня окунуло в DDD.
DDD — вроде бы про язык. Про общее понимание между бизнесом и разработкой. Про то, чтобы сложное стало чуть понятнее. А теперь откройте любую из «каноничных» книг по DDD. Хотите у Эванса, хотите у Вернона. Хотите даже у Хононова. А теперь найдите там внятное определение домена. 🙃
Сюрприз: его там… нет. Есть
Domain (noun)
a sphere of knowledge, influence, or activity.
(сфера знаний, влияния или деятельности)
Словарь Мерриам-Вебстера
И есть «реальность бизнеса». Есть «область, где компания зарабатывает деньги». И вроде бы звучит хорошо — но когда ты на митапе или на курсе начинаешь объяснять, «что такое домен», и люди в зуме кивают, а потом кто-то говорит, что у него домен — это API, ты понимаешь, что все не так просто.
Когда-то я села и попыталась сформулировать определение для себя. Чтобы не спорить бесконечно. Чтобы использовать на мастер-классах, митапах и т.п.. И вот что у меня получилось:
Домен – это ограниченная часть бизнеса, имеющая свою бизнес-ценность (отдельно оцениваемую), позволяющая при его исключении, работать остальным доменам бизнеса в рамках их основного продуктового назначения, с частичной (или отсутствующей) деградацией.
Звучит сухо, но очень помогает. Вот убрать «платежи» — и остальное работает, просто не зарабатывает. А вот убрать «логистику» — и часть бизнеса встанет, но остальное будет жить. Значит, это отдельные домены. А вот «авторизация» — это не бизнес-домен, а скорее техническая компонента, обвязка.
Важно: я не настаиваю, что это единственное правильное определение. Но пока — это единственное, которое мне действительно помогает дизайнить архитектуру и язык.
С ним можно обсуждать приоритеты. Можно находить ядро. Можно на пальцах объяснить, почему часть системы — это не просто модуль, а именно бизнес-домен со своей логикой и ценностью.
Хотя термин «домен» в контексте DDD порой размытый, важно явно договариваться о его значении в каждом конкретном случае. Авторы основных книг по DDD – Эванс, Вернон, Хононов – закладывают понимание домена как предметной области бизнеса, но уровень этой области может различаться (весь бизнес vs. отдельная функция). Если мы уточним, что домен – это обособленная часть бизнеса с самостоятельной ценностью, то получим более четкую основу для стратегического дизайна.
💬 А вы как определяете «домен» в своей работе? И как объясняете это команде?
#architecture