Эээ... Microkernel?

Правильное использование BPM состоит в том, что формально и приблизительно определенный процесс ужЕ задает архитектуру и скелет решения, которое может итеративно уточняться и изменяться - см.   http://improving-bpm-systems.blogspot.bg/2016/08/better-application-architecture-apparch.html

Этот подход хорошо работает с платформенной архитектурой - см. http://improving-bpm-systems.blogspot.bg/2017/05/beauty-of-microservices-making-them.html

http://software-pattern.org/Microkernel, например.

Связи не увидел.

Получается, что пратформа это мега ядро (kernel)?

Архитектурно - да. Она в какой-то степени фиксирована, в такой же степени абстрактна, предъявляет определенные требования к интерфейсам и контрактам.

Вообще-то, платформа – это не монолит как ядро. Понятно, что жизненный цикл решений на базе платформы сильно отличается от жизненного цикла самой платформы. Однако развитие платформы может происходить путем постепенного и независимого развития ее компонент.   http://improving-bpm-systems.blogspot.bg/2016/01/achieving-synergy-between-diversity-and.html

О процессах и идее микроядра: думаю, что дело не в платформе, а в подходе к дизайну. Часто создатель процесса считает своим долгом точно прорисовать все активностии. Потом такой процесс усложняется, т.к. реализация конкретного экзеспляра приносит что-то новое и очень скоро из модели процесса получается "схема старого телевизора" Это не всегда оправдано. Иногда лучше сделать некий "базовый" процесс - просто набор стадий, а детализацию работ внутри стадий оставить на потом. По-сути, мы говорим о таком процессе(скорее кейсе) как о базовом классе из которого можно наследовать конкретные детализации процесса для разных частных случаев. Реализацию такого процесса можно разбить по системам: основные вехи отслеживать в одной, а конкретные задачи делать в других. Но это, скорее, полезный "побочный эффект"

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

+1

По-моему, так и есть. Только что такое плагинная архитектура в этом случае? Это по сути наличие двух глобальных типов компонентов - ядра и плагинов и их взаимодействие. Ядро реализует какую-то логику (в сочетании с инверсией управления - логику вызова интерфейсов плагинов), которая более-менее фиксирована и часто абстрактна (т.е. не задает жестких ограничений на детали), а плагины реализуют логику конкретных сервисов (в широком смысле). То есть такой себе системного уровня паттерн. При этом, как Максим уже говорил ранее, ядро может быть максимально абстрактным, не реализующим вообще никаких конкретных бизнес-требований, например, CMS. Или может быть более конкретным, более бизнес-специфичным (яркий пример - платформа 1С). Ограничений на дальнейшую архитектуру самого ядра и плагинов тоже нет.

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

1С вы можете запустить без плагинов, Eclipse тоже и т.п, это Microkernel

Смотря что считать плагином. Судя по их же собственному описанию, ядро - это платформа (т.е. по сути модули, обеспечивающие функциональности НСИ и вызовов различных интерфейсов конфигураций). А "плагины" в терминах Microkernel - это конфигурации, которые на этой платформе запускаются (Бухгалтерия, Консолидация или кастомные и т.д.). Так что в этом смысле 1С, конечно, можно запустить без этих "плагинов", но функциональность реализовывать она не будет. По крайней мере, бизнес-значимую

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

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

Суть в механизме расширения. Наследник не всегда плагин

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

Spring - это же фреймворк, а не микроядро. В нём почти всё на абстракциях