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

Ну, а это то, что тебе надо? Внутри домена зависимости не очень страшны. А для системных сервисов важнее гибкость и простота одновремено.

Т.е. это все равно на команде ответственность? Если ошибуться, ты об этом не узнаешь

И для всех важна 'доменная модель' стоящая за API, насколько она универсальна. а ее оценить сложнее

близко)
это-ж наша стандартная боль,
“а давайте вот тут быстренько добавим одно поле”,
потом оказывается что на другом конце системы на него завязана логика.
Итого разные части системы неявно связаны в монолитное поведение.
Задача: пресечь такие кейсы в зародыше.

А как ты пресечешь, если это про бизнес-логику?

локализацией прикладной логики в рамки одного сервиса-оркестратора(хореографа).
то что он вызывает может предоставлять лишь обеспечивающие функции

ну, к сожалению, ответственность "на команде" в долгую работает лучше чем "ответственность на аудиторе"

Ну, если у тебя два домена связаны, то они связаны через данные в том числе.

Если у тебя есть "комиссия системы", то она нужна и при отображении пользователю и в процессинге и в тарифах и еще куча где.

Мы идеалисты, цель - сделать так чтобы данные были в форме звезды с одним центром в продуктной вертикали

Ну, если вертикаль - это один контекст в смысле DDD, то можно.
Но тогда надо проверять только "чистоту" по данным (в стиле чистой архитектуры), что между слоями ничего не бегает лишнего.

Т.е. явно прописывать многослойный пирог сервисов и в нем выстраивать потоки данных и команд.

Я думаю, что если есть, то на сайте Уорда об этом точно должно быть написано: wiki.c2.com . Нужно только знать по каким терминам искать.

Оценивать насколько они контекстно зависимы в рамках проекта, чем меньше доменных вещей проекта, тем больше шансов переиспользовать

Ну вот я видел сервисы без доменных связей, но без возможности их переиспользовать.
Не гибкие или слишком гибкие или просто неудобные или ещё что.

Как пример https://github.com/zalando/zally для валидации zalando api guidelines

https://github.com/stoplightio/spectral с настраиваемыми правилами

https://nordicapis.com/8-openapi-linters/ тут еще подобные тулы

Давно присматриваюсь к такой задаче, но все не доходило.

Тоже есть такое

Коллеги, добрый день! HELP🙋‍♂️
⬆️Подскажите варианты решения задачи!⬆️
Поставили на проект. Внедряем заказное ПО уже год.
Кода нет, техдокументации кроме пользовательских инструкций полугодовой давности нет.
В договоре обязательств подрядчика передать код и техдокуметацию тоже нет.
Попросил код и техдокументацию на проект у разработчика.
Ответ:
Техническая документация разрабатывается после завершения работ по проекту.
Такое возможно в принципе: не документировать ПО по ходу работ в течение года разработки?
Подготовить документацию будет стоить денег, рассчитаем после получения списка и требований к техдокументации.
Нормальная практика? Что просить?

Если удобно - можно в личку!
Заранее СПАСИБО!