Без заголовка

Подумалось. Про акторов и сервисы. Их близость (иногда до степени неразличимости) исходит во многом от ролевой модели определения акторов. Т.е. если актор - это роль, которую они играет в процессе, то очевидно, что в сервисном описании эта роль сопровождается конечным набором сервисов, которые данный актор по идее должен предоставлять (условному) процесс-менеджеру для того, чтобы процесс работал и совершенствовался. Другой вопрос связан с тем, что есть довольно непустое (иногда также до степени смешения) пересечение между акторами и стейкхолдерами. А роли стейкхолдеров в процессе не так модельны, т.е. могут меняться. Все это заставляет задуматься о том, что есть capabilities (например, выразимо ли они через сервисы), и как стыковать их (а значит и сервисы) с стейкхолдерами (и их ресурсами). Еще также про каталог методических комплектующих. Если Вы хотите method parts, то Вам (очевидно) не обойтись без моделей интеграции этих запчастей в общий метод. Тут, очевидно встает вопрос - а можно ли выразить эту модель опять же через сервисную логику. И как это сделать - специальным языком, на котором можно было бы писать компиляторы более сложных сервисов на основе более простых? И не соответствует ли это тому, что в пределе любой процесс можно представить как сервис, а в method parts хранить только описанные на этом языке субпроцессы, и так вниз по иерархии до каких-то элементарных процессов. Ведь в этом случае дизайн системы это не более чем выбор базы элементарных комплектующих + система скриптов, описывающих иерархическую модель, по которой данная система собирается в единый сложный сервис.