Как стать автором
Обновить

Доменная структура. Как организована продуктовая разработка в Ozon

Время на прочтение12 мин
Количество просмотров12K
Всего голосов 30: ↑29 и ↓1+30
Комментарии5

Комментарии 5

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

крутая статья, спасибо

А кто у вас отвечает за общую системную ИТ архитектуру в кросс-доменных проектах? Есть ли какие-либо архитекторы например, уровня enterprise или домена более высокого уровня логистики которые решают в каком поддомене будет реализована та или иная часть проекта? Или в рамках кросс-доменного проекта сотрудники каждого домена решают это самостоятельно в рамках обсуждения рабочей группы, но тогда как решаются спорные вопросы если не удается прийти к взаимному согласию по каким-либо моментам?

У нас нет выделенной роли архитектора во всем Озонтехе. CTO принципиально против.

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

А вот к какому домену отнести - это немного другое. Это уровень бизнес-логики, из которой и следует архитектура. Тут мы исходим из логики деления на домены (предметные области). Обычно легко удаётся договориться, поскольку границы доменов очерчены. Если же не удаётся - обычно это означает, что "демаркация" не доделана до конца. Вот тут включается более сложный процесс, в котором принимают участие все, кого затрагивает передел границ.

Здесь я не буду вдаваться в подробности того, как устроено проектное управление в Ozon, — это тема для отдельной статьи.

Вот о самом любопытном как раз умолчали! Что "исповедуете" - SAFe, LeSS или что-то самобытное?

Самобытное :)

Умолчал потому, что тянет на отдельную статью. В этой и так букв хватает.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий