emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.

Начнем с Solution Space, или почему вносить изменения в проект становится дорого. В начале 2000-х размер средней системы на рынке постоянно возрастал и достиг такого предела, когда создавать системы по-старому было уже затруднительно. Основных сдерживающих…

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

💬️ “Модель - это упрощение; это такая интерпретация реальности, при кото­рой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются.

A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.”

—“Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans, перевод В.Л. Бродового

Я затрудняюсь в точном переводе термина problem. И хотя употребление термина "проблема" не совсем корректно, но термин "задача" (task) тесно ассоциируется в SDLC с запросом на системный инкремент (т.е. о том, как нужно изменить конструкцию). Поэтому я предпочитаю придерживаться термина "проблема".

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

Но если мы посмотрим на оригинал как на сотрудника, то нам его масса станет нерелевантной, зато релевантными станут его должность, отдел, обязанности и т.п. Которые, в свою очередь, будут нерелевантными в контекста определения степени загрузки лифта.

А вот для столовой нам будет релевантно только то, есть ли у человека какая-то предписанная ему диета и имеются ли аллергические реакции.

Если мы посмотрим на оригинал как на плательщика, то нам будут релевантными только его платежные реквизиты.

Если мы посмотрим на оригинал как на получателя товара, то нам будут релевантыми адрес и время вручения груза.

В перечисленных моделях рассматриваются совершенно различные аспекты оригинала.

У @StanislavBolsun есть хороший Long Read по моделированию.

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

YouTube

Ярослав Лопухин. Введение в прикладной системный анализ: модели и моделирование

Докладом “Модели и моделирование” мы продолжаем цикл лекций по прикладному системному анализу, посвященных памяти замечательного ученого и педагога Ф.П. Тарасенко.

Главный рабочий инструмент системного анализа — модель. Построенная модель становится средством…

www.tgoop.com/emacsway_log/1383

2.2K viewsIvan, edited  Apr 23, 2024 at 06:20

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

💬️ “Модель - это упрощение; это такая интерпретация реальности, при кото­рой из явления извлекаются существенные для решения задачи аспекты, а лишние детали игнорируются.

A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.”

—“Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans, перевод В.Л. Бродового

Я затрудняюсь в точном переводе термина problem. И хотя употребление термина "проблема" не совсем корректно, но термин "задача" (task) тесно ассоциируется в SDLC с запросом на системный инкремент (т.е. о том, как нужно изменить конструкцию). Поэтому я предпочитаю придерживаться термина "проблема".

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

Но если мы посмотрим на оригинал как на сотрудника, то нам его масса станет нерелевантной, зато релевантными станут его должность, отдел, обязанности и т.п. Которые, в свою очередь, будут нерелевантными в контекста определения степени загрузки лифта.

А вот для столовой нам будет релевантно только то, есть ли у человека какая-то предписанная ему диета и имеются ли аллергические реакции.

Если мы посмотрим на оригинал как на плательщика, то нам будут релевантными только его платежные реквизиты.

Если мы посмотрим на оригинал как на получателя товара, то нам будут релевантыми адрес и время вручения груза.

В перечисленных моделях рассматриваются совершенно различные аспекты оригинала.

У @StanislavBolsun есть хороший Long Read по моделированию.

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

BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.