Здесь и далее я буду рассматривать общекнижный пример с сотрудниками предприятия, писать будем на чем-то СИ-подобном. Наследовать класс Сотрудник (Employee) от класса Человек (Person) – прекрасная идея, особенно если хранить данные исключительно в памяти: SQL имеет некоторые проблемы с наследованием таблиц, но речь не об этом — ООП со своим иерархизмом, агрегациями, композициями и наследованиями предлагает идеальный способ организации данных. Проблемы с методами.
За каждым методом бизнес-логики стоит факт мира, который этот метод (чаще не в одиночку) моделирует. Факты программирования – это операции: дальше будем называть их так. Делая метод членом класса, ООП требует от нас привязать операцию к объекту, что невозможно, потому что операция – это взаимодействие объектов (двух и более), кроме случая унарной операции, чистой рефлексии. Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им. Дилемма о расположении методов сопутствует всему процессу разработки: неловкое ее разрешение может оказаться критичным и даже фатальным.
В книгах по программированию честные авторы стыдливо признают, что «объекты – это как бы не совсем объекты», а ООП – всего лишь способ организации кода, а не механизм моделирования. Но все дело том, что «мир есть совокупность фактов, а не вещей» – отсюда принципиальная неспособность построить адекватную модель, применяя ООП в том виде, как этого требуют писатели учебников. Важно понять: в коде возможно моделировать мир, но атомами модели должны стать факты, а не объекты.
Оказавшись два года назад в мире разработки ПО, я с ужасом осознал, что тут до сих пор царит Аристотель: ООП – прямое порождение его философии. Этот одиозный мыслитель придумал флогистон для химиков, движущую силу для физиков – да что там говорить! — приложился к каждой из крупных дисциплин. История европейского прогресса – это история преодоления Аристотеля. Науке он принес больше зла, чем вся Святая инквизиция. Две тысячи лет потребовалось нашим ученым, чтобы затереть следы его «Физики». ООП – последнее пристанище его мрачной тени. Встречаясь с ним здесь — в ядре самых передовых технологий — хочется взять античный
Людвиг Витгенштейн (его афоризм вынесен в заголовок) интересен тем, что, будучи доктором философии, не прочитал и двух страниц из Аристотеля: это его – Витгенштейна — слова. Неудивительно, что неопозитивизм – единственная «работающая» философская система, по сути – единственная на сегодня корректная философия: в подтверждение могу упомянуть, например, неопозитивиста Карла Поппера, который разработал современную методологию научного познания.
Функциональное программирование стало интуитивной реакцией миллионов разработчиков на туманность ООП – его полным отрицанием. Сам я не вижу причины в том, чтобы вовсе отказываться от иерархических принципов: в них много удобного. Известные языки не предлагают готовых средств для строительства иерархии операций, и мне сейчас сложно представить, как должен выглядеть ее синтаксис и звучать ключевые слова. Перенести фокус с объекта на операцию можно и наличными средствами: любой известный ООП-язык с этим справится.
Для начала разделим бизнес-логику на два пространства: данные и операции. Пространство данных не представляет собой ничего особенного – это классы данных, построенные в обычную иерархию – живущие только в оперативной памяти (POJO) или с возможностью сохранения состояния (сущности .NET, модели YII). Классы данных могут располагать собственными методами, как того требует фреймворк: принципиально лишь, чтобы эти методы не имели отношения к бизнес-логике.
Public Class Account {
Public string accountBankName;
Public string accountMfo;
Public string accountNumber;
}
Public Class Company {
Public string companyTitle;
Public string companyPhone;
Public Account companyAccount;
}
Public Class Department {
Public string departmentTitle;
Public Company departmentCompany;
}
Public Class Person {
Public string personName;
Public date personBirthDate;
}
Public Class Employee inherits Person {
Public Department employeeDepartment;
Public double employeeSalary;
Public Account employeeAccount;
}
Есть компания (Company) с несколькими подразделениями (Department) и сотрудниками (Employee), унаследованными от класса людей (Person). У компании есть счет (Account), с которого сотрудникам перечисляется зарплата. Соответственно, счет (Account) для получения зарплаты есть и у каждого сотрудника. Предположим, что наша программа должна уметь:
— принимать сотрудника на работу;
— выплачивать сотруднику зарплату;
— увольнять сотрудника с выплатой выходного пособия;
Прием на работу и увольнение сотрудника можно назвать кадровыми (Staff) операциями, а выплату выходного пособия и зарплаты – бухгалтерскими (Accounting) операциями.
Для каждой из операций понадобится:
— инициализировать данные о компании;
— инициализировать данные о сотруднике;
— распечатать некий документ.
Для приема / увольнения сотрудника нам придется:
— инициализировать данные о соответствующем подразделении фирмы;
Для двух указанных бухгалтерских операций нам также понадобится:
— инициализировать данные о банковских счетах сотрудника и компании.
Переходим к главному – собственно пространству операций. Мы реализуем его как иерархию классов, каждый из которых представляет собой нечто, что мы назовем «контекст операций» (Operation Context). Публичными методами (API) этих классов будут операции бизнес-логики, а свойства и приватные методы помогут в формировании абстракций. В соответствии с принятым ранее разделением, в нашей программе появятся классы StaffOperationContext и AccountingOperationContext, унаследованные от базового BaseOperationContext. Уложить вспомогательные члены в иерархию операций окажется проще, чем в иерархию объектов.
Public Class BaseOperationContext {
// конструкторы
BaseOperationContext () {
InitCompanyData();
}
BaseOperationContext (Employee employee) {
InitEmployeeData(Employee employee);
InitCompanyData();
}
// приватные и защищенные методы
private void InitCompanyData();
private void InitEmployeeData(Employee employee);
protected void PrintDocument(Document doc);
}
Public Class AccountingOperationContext inherits BaseOperationContext {
// конструкторы
AccountingOperationContext () {
super();
}
// приватные и защищенные методы
Private InitAccountData(Account account);
Private BankTransfer(Account account, Double amount);
// публичные методы – API класса
Public void PaySalary (Employee employee) // выплата з/п
{
// … некоторый кусок логики
InitAccountData (employee.employeeAccount);
// … некоторый кусок логики
BankTransfer (employee. employeeAccount, salaryAmount);
// … некоторый кусок логики
PrintDocument (someSalaryPayDocument);
}
Public void PayRedundancy (Employee employee) // выплата выходного пособия
{
// … некоторый кусок логики
InitAccountData (employee. employeeAccount);
// … некоторый кусок логики
BankTransfer (employee. employeeAccount, redundancyAmount);
// … некоторый кусок логики
PrintDocument (someRedundancyPayDocument);
}
}
Public Class StaffOperationContext inherits BaseOperationContext {
// конструкторы
StaffOperationContext (Employee employee) {
super(employee);
}
// приватные и защищенные методы
Private InitDepartmentData(Department department);
// публичные методы – API класса
Public void RecruitEmployee (Person person, Department department) // прием сотрудника
{
InitDepartmentData(department);
Employee employee = person;
// … некоторый кусок логики
PrintDocument (someRecruiteDocument);
}
Public void FireEmployee (Employee employee, Department department) // увольнение
{
InitDepartmentData(department);
// … некоторый кусок логики
// инициализируем AccountingOperationContext для платы выходного пособия
AccountingOperationContext accountingOC = new AccountingOperationContext ();
accountingOC.PayRedundancy (employee);
// .. некоторый кусок логики
PrintDocument (someFireDocument);
}
}
Этим кодом мы ломаем принципы ООП: наш метод FireEmployee относится к своему классу StaffOperationContext как «является», а не «содержится»: то есть увольнение сотрудника становится частным случаем кадровой операции (наследником), а не ее элементом (членом). Компенсацией будет обретение здравого смысла. Некорректное высказывание «увольнение сотрудника является членом объекта 'сотрудник'» мы заменяем на корректное «увольнение сотрудника является кадровой операцией». Корректность высказываний дает надежду на построение корректной модели.
Проблема детерминации (какой метод куда положить) не кажется разрешенной по умолчанию, но она разрешима. В своем единственном разработанном «по Витгенштейну» приложении я опирался на интерфейс. Имея на фронт-энде около десяти экранов, я разбил логику на десять контекстов операций с базовым контекстом наверху иерархии.
Можно по-разному классифицировать операции, важен сам принцип: объектно-ориентированное программирование мы заменяем на операционно-ориентированное. Еще раз повторюсь: речь идет исключительно о бизнес-логике – мире программы. Использовать классы среды и порождать их наследников ничто не мешает.
Не имея широкой айтишной эрудиции, могу предположить, что подобные мысли уже посещали многих философов и программистов. Вероятно, они были даже представлены в форме текстов – независимо и многократно. Сам я с подобными изысканиями не встречался, и мне потребовалось два года, чтобы прийти самостоятельно к этому удачному – как мне кажется – сочетанию объектно-ориентированного и функционального программирования (так представляется внешне).
Описанным способом я реализовал бизнес-логику в своем последнем на сегодняшний день проекте. В результате полного рефакторинга (проект достался мне по наследству) код сократился на 70% и стал невероятно дружественным в отношении любых — даже весьма значительных — правок. Опыт вышел удачным: предлагаю попробовать.
Комментарии (44)
4dmonster
13.10.2016 10:54Некорректное высказывание «увольнение сотрудника является членом объекта 'сотрудник'» мы заменяем на корректное «увольнение сотрудника является кадровой операцией».
А почему для примера используется недоделанная ООП иерархия?
Где классы «Сотрудники»? «Департаменты»?
ApeCoder
13.10.2016 11:35трудовойДоговор.расторгнуть() :)
4dmonster
13.10.2016 11:45+3Ну да, или, если не чинить, структуру, то:
Сотрудник.Уволиться()
Организация.Уволить(Сотрудник)
Собственно, почти все критики чего-либо, как правило, чего-либо сначала ухудшают.ApeCoder
13.10.2016 12:02+3Мне кажется, судя по количеству дублирования в коде, непонятным идентификаторам и выбору Delphi в качестве языка для рассуждений об ООП автор не очень подкован в предмете своих рассуждений. И в предметной области, которую выбрал для примера.
ApeCoder
13.10.2016 11:34Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им
Мне кажется зарплата термин специфичный именно для отношений между людьми и предприятием, а это отношение и обозначается термином Работник.
То Касса и Банковский счет могут быть использованы и в других контекстах.
Deosis
13.10.2016 12:02В модели связи прописаны как в БД, из-за этого логика страдает:
Чтобы выплатить зарплату сотрудникам некоторой компании,
мы должны просмотреть все департаменты в мире во всех компаниях, чтобы узнать сотрудникам каких департаментов выплачивать зарплату,
Потом просмотреть всех сотрудников в мире, чтобы узнать, кто из них работает в найденных департаментах.
И только затем можно выплатить зарплату.
Больше похоже на попытку реализовать хранимые процедуры СУБД в коде.
lair
13.10.2016 12:03+9Есть маленькая проблема: поскольку реализациия операции не является деталью реализации объекта, вы теперь не можете это инкапсулировать. В частности, если операция "увольнение" проставляет объекту "сотрудик" флаг "уволен", то как вы реализуете требование "флаг "уволен" может быть проставлен только в ходе операции "увольнение""?
Далее, группировка операций по "контекстам" не имеет никакого смысла с точки зрения разработки: операции в рамках "контекста" друг с другом, на самом деле, не связаны. С равным успехом можно вынести каждую операцию в отдельный "контекст" и получить, по большому счету, паттерн
Command(с определенными оговорками) — каковой паттерн, будем честными, полностью объектно-ориентирован.
Но по большому счету, то, что у вас описано, называется Transaction Script и описано Фаулером в PoEAA больше десяти лет назад.
сочетанию объектно-ориентированного и функционального программирования
Не-а. Ваш код остался объектно-ориентированным. Модель — нет, но модель — это не код. И ваш код не приобрел ничего от функционального программирования, потому что практически первое, чем ценно функциональное программирование — это отсутствие побочных эффектов; у вас же каждая операция порождает эти побочные эффекты во множестве.
Ramires
13.10.2016 12:08+3Науке он принес больше зла, чем вся Святая инквизиция.
Ок, низвергаем мыслителей древности, идём дальше.
Две тысячи лет потребовалось нашим ученым, чтобы затереть следы его «Физики».
Я бы не клеймил так его трактат, ведь он заочно полемизировал в своих трудах с другими учеными своего времени. На его труды опирались последующие поколения учёных. Пусть он был не прав, но давал пищу для размышления.
хочется взять античный стилус (так в Риме называли палку погонщика скота)
Что? Вы про стилос?
единственная на сегодня корректная философия
Вы про ранний или поздний период его работы? Они достаточно сильно отличаются, в позднем он отказался от многого, что утверждал в раннем.
«Единственная»? Как-то очень много пафоса в нескольких абзацах.
Функциональное программирование стало интуитивной реакцией миллионов разработчиков на туманность ООП – его полным отрицанием.
Прочитайте вот это
В комментариях верно заметили — вы изобрели зоново паттерн Медиатор
third112
13.10.2016 13:01+1низвергаем мыслителей древности
Да. И между прочим, кроме физики, он принес еще Аристотелеву логику, легшую в основу (с определенными переосмыслениями) современной мат.логики. Чтобы мы сейчас делали без логики? Как бы программировали?
dcc0
13.10.2016 14:01+1Пусть он был не прав, но давал пищу для размышления.
Что в глазах любителей «прорывов в науке» должно оправдывать большинство теоретических рассуждений, гипотез и вообще текстов на habrahabr.ru
единственная на сегодня корректная философия
Я бы не советовал делать таких утверждений без вводной конструкции «Я считаю» или «Мне так кажется».
Halt
13.10.2016 13:51Вообще-то палка погонщика называлась стимул. А стилус это таки средство письма. Фейл.
third112
13.10.2016 14:13+2В книгах по программированию честные авторы стыдливо признают, что «объекты – это как бы не совсем объекты»
Пожалуйста, приведите пару ссылок на эти книги.
Оказавшись два года назад в мире разработки ПО
Очень не большой срок.
Неудивительно, что неопозитивизм – единственная «работающая» философская система, по сути – единственная на сегодня корректная философия: в подтверждение могу упомянуть, например, неопозитивиста Карла Поппера, который разработал современную методологию научного познания.
Методология Поппера далеко не единственная и не общепризнанная, как и философия неопозитивизма.МногиеВсе другие философии настаивают на своей истинности. Говоря упрощенно (на уровне упрощений статьи) философия — это тоже модель. А в моделировании нетривиальных сущностей, ситуаций и т.д. не бывает, чтобы одна модель полностью исключала все другие. Одна модель использует одни свойства прототипа и больше подходит для одних целей, другая — другие и больше подходит для других целей.
Функциональное программирование стало интуитивной реакцией миллионов разработчиков на туманность ООП
Функциональное появилось раньше: лямбда-исчисление (Алонзо Чёрч, 1930), Лисп (конец 1950х), т.е. раньше, чем Simula 67.
Пример ИМХО слишком тривиальный для критики методов в ООП. Взять пример сложнее, и мы увидим роль полиморфизма и т.д.
Durimar123
13.10.2016 15:09+2Проблема некоторых разработчиков в том, что они отождествляют class из ООП с некими существующими объектами. Отнюдь, class может представлять собой не только существительное, но и глаголы и прилагательные.
Поэтому «выдача/получение зарплаты» сама может быть объектом.
И не смотря на то, что из ООП кто-то пытается сделать религию, а другие дьявола, лично для меня, это всего лишь удобный инструмент.ApeCoder
13.10.2016 19:58class может представлять собой не только существительное, но и глаголы и прилагательные
В естественном языке тоже есть существительные, сделанные из глаголов
Durimar123
13.10.2016 15:16+1По моему автор этого опуса, не понял ООП, а когда разобрался, то что бы не считать себя дураком, обвинил в своей косности систему.
Ну что сказать удобно — все дураки, только один я Дартаньян!
MaxxArts
13.10.2016 15:20-1Неплохо для начала самостоятельных изысканий. Мысли и желания идут в верном направлении. Если не хотите тратить много времени, то вот вам ключевое слово — DDD.
Shamov
13.10.2016 16:38Критерий научности Поппера не выдерживает рекурсивной проверки самого себя. Поэтому его претензии на универсальность совершенно не обоснованы. Но за упоминание Витгенштейна зачёт. Всегда приятно видеть признаки хорошего гуманитарного образования. Описанная методика реализации операций на базе контекстов, конечно, отстой. Но не вообще в целом, а только данное конкретное воплощение. В качестве примеров выбраны крайне неудачные объекты и операции, на которых преимущества методики не видны. Они её скорее дискредитируют. Хотя очевидно, что существуют такие операции, которые действительно нельзя корректно привязать ни к какому объекту. Вот на их примере методика заиграла бы совсем иными гранями и выглядела бы достойно.
ApeCoder
13.10.2016 20:00Критерий научности Поппера не выдерживает рекурсивной проверки самого себя
Это общеизвестный факт или вы сами додумались? Можно ли ссылку на источник?
napa3um
13.10.2016 20:07+1https://ru.wikipedia.org/wiki/Проблема_демаркации
(Не делайте из науки атеистическую религию Великого Пруфа.)
Shamov
13.10.2016 21:22Очевидно, не общеизвестный… раз вы об этом спрашиваете. Скажем так, это общедоступная информация. Более того, об этом нетрудно догадаться самому. Поппер преподносит нам свой критерий как некую догму. Мы должны просто тупо уверовать в то, что это как раз и есть единственно верный способ определения научности. По идее, он должен был бы дополнить свой критерий рассуждением типа: «Если бы этот критерий не работал, то мы бы могли очень легко это обнаружить, поскольку увидели бы то-то и то-то. А раз мы этого не видим, то значит критерий работает.»
Но это всё не очень интересно, поскольку почти тривиально. По-настоящему интересное написано в книге Пола Фейерабенда «Против метода». Она не конкретно про критерий Поппера, а про то, что научный метод в целом — это фуфло.stokker
14.10.2016 00:52Более того, с точки зрения философии даже абсолютность науки недоказуема ))
Shamov
14.10.2016 07:24В философии никто даже не пытается доказывать этот заведомо ложный тезис. Любой адекватный философ знаком с понятием онтологии и прекрасно понимает, что научная онтология является лишь одной из многих. Тем не менее, это всё-таки полноценная онтология. А значит её можно инсталлировать в мозг в качестве единственной и не знать никаких проблем, объясняя всё вокруг исключительно через неё.
napa3um
14.10.2016 10:17> А значит её можно инсталлировать в мозг в качестве единственной и не знать никаких проблем
Нельзя, да и не получится, «проинсталлируется» только уверенность в том, что наукообразные формулировки — истинны (и агрессия к «гумманитариям», в которые записываются все несогласные). Большинство «бытовых» коммуникаций людей лежат не в сфере выяснения объективной истины, а в сфере синхронизации мнений и вкусов. Часто путают знание фактов с пониманием принципов. Часто называют оценку рисков логическим доказательством. Часто называют умным (научным, объективным, истинным) то, что совпадает с их точкой зрения. Научный метод — лишь один из множества формальных инструментов познания, им не заменить человеческое мышление.pokryshkin
01.02.2017 23:11Пара вариантов: привязываете силовой блок торшера к нескольким выключателям (свет торшера и верхний свет). В этом случае выключатель верхнего света будет также отключать и торшер.
Сценарии. Назначаем на сценарную кнопку включение всего света (т.е. привязываем к ней весь свет).napa3um
14.10.2016 11:01У научного метода лишь одно назначение — накопление объективных («очищенных» от влияния субъективности), разделяемых, проверяемых знаний. В жизни человека таких знаний не так уж и много, чаще всего человек при принятии решений обходится своей необъективизированной, неформализованной картиной мира из набора разрозненных шаблонов и эмоций. Более того, сам научный метод — не статичный набор аксиом, а консенсус развиваемых философских точек зрения, имеющий разное состояние в разное время и в разных коллективах. Ваша [обращение к неопределённому кругу читателей] вера в науку — завуалированная попытка отнесения себя в социальной иерархии к более высоким позициям, не более того.
napa3um
14.10.2016 11:08P.S.: Про «всё может быть объяснено наукой», кстати, вы опоздали на сотню лет, в современном научном методе «объяснительная сила» теориям не требуется, требуется лишь «практическая воспроизводимость опыта». Как сказал Дэвид Мермин: «Заткнись и считай!» Объяснительные интерпретации — удел метанаук и философии.
third112
14.10.2016 12:00Как сказал Дэвид Мермин: «Заткнись и считай!»
Интересная, хоть и популярная публикация на эту тему: Андрей Борисов, Заткнись и считай (Кого не удовлетворит популярный уровень: см. в конце статьи ссылки на научные издания).
mnikolaev83
15.10.2016 11:26-1Друзья! Благодарю за ваше внимание, ссылки, комментарии, указания на шаблоны. Именно такой информации я ждал от вас — опытных разработчиков, — поднимая этот вопрос. Спасибо!
Говоря о Витгенштейне, я подразумеваю ранний период: некоторые базовые положения Логико-Философского трактата — это представляется очевидным, исходя из написанного. Логика, как-то сформулированная Аристотелем, не была им открыта. Она предшествовала не только грекам, но и человеку — и даже миру, возможно. Не будем углубляться в метафизику. Здесь я остаюсь при своем мнении: Аристотель бесполезен как философ и крайне вреден как лжеученый.
Набросок кода, написанный «на языке Deplhi» (на самом деле, это несуществующий язык с понятными на слух ключевыми словами), я придумал и привел здесь, чтобы не быть голословным. Мне просто был нужен пример. Этот удобен тем, что использует минимум средств языка и платформы. Имея богатые средства, можно сделать лучше. Для меня выжным было показать не инженерный, а философский принцип: адекватное моделирование требует рассматривать факты, а не объекты. Мы-то с вами знаем, что, в отличие от какого-нибудь авиастроения, программирование имеет синтетическую природу: с одной стороны оно — раздел практической философии (как математика), а с другой — инженерная дисциплина. Все, что я тут написал, касается философии исключительно.
PS Отдельное спасибо за бдительность!:) Зловредную опечатку исправил.lair
15.10.2016 14:13+1адекватное моделирование требует рассматривать факты, а не объекты
Нет, не так. Адекватное моделирование требует рассматривать то, что представляет интерес в предметной области.
third112
15.10.2016 16:20+1в отличие от какого-нибудь авиастроения, программирование имеет синтетическую природу: с одной стороны оно — раздел практической философии (как математика), а с другой — инженерная дисциплина
К «какому-нибудь авиастроению» Вы явно не справедливы: программирование входит и в современное авиастроение, начиная с систем автоматического проектирования и кончая программированием бортовых компьютеров. То, что математика — раздел практической философии, крайне экстравагантное утверждение. Есть область философия математики, но она определяется иначе, чем вся математика.
prefrontalCortex
15.10.2016 20:58Да бросьте вы Аристотеля ругать. Они там, в древней Греции, впервые додумались думать о том, как они думают, откуда у всей науки ноги и растут.
Shamov
17.10.2016 11:28Вот здесь вы немного противоречите Витгенштейну. Ну как немного? Ненароком, всего лишь одним предложением вы полностью опровергаете всё его учение. Согласно Витгенштейну, сформулировать нечто на определённом языке как раз и означает открыть это. А применительно к логике, которая существует лишь умозрительно, правильнее будет сказать не просто «открыть», а вообще «создать». Несформулированная логика, которая кому-то предшествовала, абсолютно ни на что не влияла. Говорить о существовании несформулированной логики бессмысленно. Это всё равно, как говорить об использовании ООП, про которое никто в точности не знает, что это вообще такое. Типа, ООП — это когда ты делаешь с объектами всякие разные прикольные штуки, которые всё упрощают. Это вообще ни о чём. Когда ты говоришь об ООП в таком стиле, нельзя сказать, что ты говоришь об ООП.
napa3um
Вы изобрели паттерн проектирования Mediator («диспетчер»). И, подозреваю, очень скоро додумаетесь до Event Sourcing. (Только не стоит переоценивать философскую глубину этих паттернов, они вовсе не переиначивают ООП, операция вполне себе может быть объектом.)
vmuravlev
Мне кажется, это больше на паттерн Command похоже — задается некий контекст исполнения и собственно команда execute().
Если пофантазировать на тему развития модели классов для приведенного примера, то, операции не осуществляются же сами по себе. Их выполняют вполне конкретные агенты. ИМХО, можно было бы ввести сущности HRDepartment (кадровый отдел) и AccountingDepartment (бухгалтерия) — и вот у них могли бы быть методы fireEmployee() и payRedundancy().
napa3um
Event Sourcing (с командами и CQRS) я предположил как дальнейшее развитие диспетчера из статьи. Пока там «контекстом» названа сама кадровая бизнес-логика. Но мог и что-то недопонять.