У нашей МИС был широкий спектр ЛПУ, от частных клиник до госпиталей на 1400+ коек. И нужно было удовлетворить желания всех клиентов. В целом после кучи лет работы компании можно покрыть ~80% интересов. При этом модуль расписания разрастается, а требования всё равно приходят итерационно - от заказчика к заказчику. Так что всегда надо говорить об MVP. А MVP всегда возможно только из частного случая.

А если будете брать идею 'in general', то выйдет, что ваша система будет одновременно не будет подходить никому, придётся в спешке её допиливать.

Продайте идею -> получите финансирование -> создайте систему. Рынок МИС для ЛПУ переполнен, с кучей конкурентов. Порой авторы МИС  готовы работать несколько лет в ноль, с учётом их прошлых наработок, чтобы только через 2-3 года выйти в +.

Всё идёт через тендеры, со всеми вытекающими

Берешь врача, берешь единицы времени (например, минуты).

Строишь пересечения врач-минуты - график его работы.

Строишь пересечения пациент-врач-минуты - это график приема пациентов.

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

Слот - это в UI набор минут, располагающихся рядом и количество которых не меньше N (время, отводимое на один прием), если на это время есть работающий врач, но еще нет ничьей записи.

Вычисляется автоматически при наложении графиков

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

Это отттого, что мы не знаем о каком говорит автор. У меня вот по вопросу сложилось впечатление, что именно об этом

ага

Регистрируйся на yclients.com в бесплатном аккаунте смотришь как там все сделано)

Давай пару вопросов про tailoring задам. Оказалось, что только у тебя в этом чате в сообщении есть слово "tailoring" :)

Давай, но ответ я не гарантирую:)

У Kamil Grzybek есть reference application по планированию встреч в конференц-комнатах. Но, насколько я помню, рекуррентные встречи там не поддерживаются.
https://github.com/kgrzybek/modular-monolith-with-ddd

На эту же тему сейчас парни пилят reference application на Golang:
https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-example

Планирование можно посмотреть у Vaughn Vernon:
https://github.com/VaughnVernon/IDDD_Samples_NET/tree/master/iddd_collaboration/Domain.Model/Calendars

По поводу рекуррентности, есть https://tools.ietf.org/html/rfc5545#section-3.8.5 и куча библиотек на почти всех языках, которые его поддерживают. Есть даже расширения для постгреса, которые делают это на уровне БД:
- https://github.com/volkanunsal/postgres-rrule
- https://github.com/petropavel13/pg_rrule

Классика работы с рекуррентными событиями описана Фаулером:
- https://martinfowler.com/apsupp/recurring.pdf

И, вот, блин, не помню, но по-моему, назначение встреч используется в качестве примера в “Patterns, Principles, and Practices of Domain-Driven Design” by Scott Millett, Nick Tune. Да, точно:
https://github.com/elbandit/PPPDDD/search?q=slot&type=

Давай сначала уйду от TOGAF-трактовки термина "tailoring" :)

Давай

https://issuu.com/pragmatic-ea/docs/proof-tinaeaf , стр. 12

Как ты понимаешь сочетание слов "framework" и "tailoring" ?
Коллеги, публичный вопрос, для дела нужно

Всем привет!
Это кстати, такое простое слово, мне удивительно что у него какое-то иное понимание может быть, кроме как "изготовлять или приспосабливать что-то для определенной цели".

Смотри: если различать 4 типа дизайна (корп - орг - team - персональный), то тебе нужно сшить то, что "fits 4 design types"