Хороший вопрос ... Но сначала ... SOA? Это отличное модное слово, но его часто неправильно понимают, в основном из-за отсутствия какого-либо «реального» определения. Черт! даже Мартин Фаулер теперь называет это «ServiceOrientedAmbiguity» и поощряет людей вообще избегать этого.
На самом деле нет ответа " one " " best ". Требования, предъявляемые к ИТ бизнесом, могут быть; и обычно есть; довольно разнообразно. На эти требования часто влияют внешние факторы, такие как клиенты, партнеры, тенденции рынка, законодательство, регуляторы и т. Д. Во многих случаях эти факторы диктуют архитектуру или, по крайней мере, ставят под угрозу или ограничивают вашу способность полностью достичь того, что, по вашему мнению, может быть «лучше» "архитектура. Это также может показаться бойким, но это не мое намерение. Представление о том, что существует такая вещь, как «лучшая» архитектура, заставляет многих продолжать тратить огромные количества энергии (и денег) на ее поиск. Хотя это может не быть преднамеренным, эти перспективы часто поддерживаются людьми, которые стали доверенными лицами для одного поставщика / сообщества или продают вам процесс как продукт.
С учетом всего сказанного ... с точки зрения разработки программного обеспечения старые принципы продолжают оставаться наиболее надежным средством обеспечения соответствия бизнес-требованиям. Например,
- Разделяй свои заботы
- Слой вашей архитектуры
- Дизайн с учетом гибкости
- Проверьте слои в изоляции, а затем проверьте их вместе
- Использование методов непрерывной интеграции, чтобы регрессия стала заметнее
- Сделайте требования и спецификации вашими основными драйверами
- Инвестируйте в инструменты, инвестируйте в ваших разработчиков
- Etc ...
Обратите внимание, что здесь не упоминается ни об одном архитектурном паттерне, технологии или языке ... это потому, что они на самом деле не являются драйверами, хотя они могут быть активаторами и будут меняться в зависимости от множества факторов. Позвольте мне коснуться еще одного момента. «Бизнес-процессы» и процессы разработки программного обеспечения имеют совершенно разные проблемы, перспективы и т. Д.… Вынуждение одной из групп функционировать так же, как и другой, приведет только к полному провалу. Это не означает, что они не должны делиться обязательствами, такими как даты, функциональные результаты и т. Д. Эти группы должны отличаться друг от друга, чтобы эффективно выполнять свою работу, но, безусловно, должны находить способы донести те вещи, которые требуют общего видения. Здесь может помочь любое количество процессов проектирования и управления жизненным циклом. (Например, DDD, MSF, SCRUM, CMMI и т. Д.).
Я хотел, чтобы это было конструктивно ... надеюсь, это поможет.