Комментарии 67
Мне кажется, что большая часть описанных проблем возникает из-за того, что пытаемся создать модель классов, а структура БД является «вспомогательной» (ORM).
Но сам по себе описанный проект ближе к тем задачам, для которых разрабатывались реляционные базы. И логичнее продумывать архитектуру не от классов java, а от er диаграммы базы. В таком случае большей части описанных проблем не появится. А если вспомнить о прочих проблемах, которые приносит за собой ORM, то описанный подход выглядит как сплошная проблема.
Но сам по себе описанный проект ближе к тем задачам, для которых разрабатывались реляционные базы. И логичнее продумывать архитектуру не от классов java, а от er диаграммы базы. В таком случае большей части описанных проблем не появится. А если вспомнить о прочих проблемах, которые приносит за собой ORM, то описанный подход выглядит как сплошная проблема.
И логичнее продумывать архитектуру не от классов java, а от er диаграммы базы.
Почему именно от ERD БД, а не от ERD предметной области? Ведь БД нужна для хранения данных о доменных объектах, а не наоборот, не БД определяет состав полей доменных объектов
Отсюда возникает еще один вопрос: а не должны ли быть доменные объекты (или их представления) различными для нашего backend’a и frontend’a?
В Domain-Driven Design-е с самого начала постулируется положение о том, что есть ограниченные области предметной области (тавтология такая вот), каждая из которых оперирует своими доменными объектами. Для взаимодействия между областями есть адаптеры.
Подобный же подход, кроме всего прочего, постулируется и в SOLID, в части Interface Segregation.
Это так, мысли под утренний кофе, а не указание на что-либо.
Почему именно от ERD БД, а не от ERD предметной области? Ведь БД нужна для хранения данных о доменных объектах, а не наоборот, не БД определяет состав полей доменных объектов
Потому что ERD предметной области — это нечто достаточно эфемерное, что нельзя непосредственно воплотить в артефактах системы. А ERD БД — это вполне конкретная вещь, которую можно напрямую трансформировать в SQL код создания объектов БД, можно нормализовать и т.д. А как, например, нормализовать ERD предметной области? :)))
Как я вижу создание микросервисов для такой задачи:
Рисуем укрупненную ERD предметной области. Под неё рисуем укрупненную ERD базы и анализируем связи — где можно разрезать на микросервисы. При этом также думаем и о прочих аспектах работы пользователя с системой, но отталкиваемся именно от схемы БД.
При дроблении на микросервисы сразу же думаем, нет ли уже готовых кусков. Например, для машин и покупателей из этого примера смотрим на решения из сферы MDM — Product information management (PIM) и Customer Information Management (CIM). Изобретение велосипедов всегда чревато проблемами. :)))
После дробления на микросервисы рисуем уже детальные ERD баз (для каждого микросервиса свою схему, чтобы в дальнейшем можно было хранить все данные как в одном инстансе сервера БД для всех микросервисов, так и в множестве разных инстансов). Можно даже сразу подумать о возможном горизонтальном разбиении данных — даже запустив 100 екземпляров микросервиса, можно легко столкнуться с недостаточной производительностью. Ведь в любом случае надо контролировать, чтобы одна и та же физическая машина не была зарезервирована в одно и то же время для разных поездок. А это означает, что БД очень легко может стать узким местом. А при неудачном разбиении на микросервисы для решения такой проблемы может потребоваться переразбиение на микросервисы с нуля и переписывание большей части кода.
И только потом, когда для каждого микросервиса, который будем создавать (часть можно позаимствовать в готовом виде), продумана схема БД, надо начинать продумывать классы java, которые будут оптимально работать именно с такими данными. И эти классы наверняка будут не такими, как описаны в статье.
Без "укрупненной ERD базы" это делается еще проще.
:)))
Возможно. Мне проще сразу рисовать схему бд.
Но главное, что я хотел подчеркнуть — сперва создаем схему бд, потом, на основе схемы бд — классы java. Иначе в таких системах будет сплошной ой.
И, кстати, если создавать что-то похожее на инстаграм, то подход «от схемы БД» будет неправильным. Там другие требования к работе с данными и те же объектные БД будут прекрасно работать. И разрабатывать архитектуру надо по другому.
То есть подход к разработке архитектуры очень сильно зависит от типа разрабатываемого приложения.
Возможно. Мне проще сразу рисовать схему бд.
Но главное, что я хотел подчеркнуть — сперва создаем схему бд, потом, на основе схемы бд — классы java. Иначе в таких системах будет сплошной ой.
И, кстати, если создавать что-то похожее на инстаграм, то подход «от схемы БД» будет неправильным. Там другие требования к работе с данными и те же объектные БД будут прекрасно работать. И разрабатывать архитектуру надо по другому.
То есть подход к разработке архитектуры очень сильно зависит от типа разрабатываемого приложения.
В каких — таких системах?
ERP системы, бухгалтерия, торговля, логистика и т.п. Реляционные СУБД создавались в первую очередь в расчете на такие задачи, и очень хорошо для таких задач подходят.
Сервис по аренде автомобилей относится к этому «типу» приложений.
А тот же инстаграмм — это уже другой тип приложений.
Сервис по аренде автомобилей относится к этому «типу» приложений.
А тот же инстаграмм — это уже другой тип приложений.
Если условный java(ака C с классами) подход не очень подходит, а РСУБД подходит хорошо, то не встаёт ли вопрос, что всю значимую логику нужно перенести в БД? Если решили, что приоритет у ООП, то вопрос выбора хранилища становится вторичным — ничего значимого доверять ему нельзя, хотя и не стоит ради принципа избавляться от протечек абстракций, дающих значимые (обычно в плане консистентности данных и производительности аналитических отчётов) преимуществ
Потому что ERD предметной области — это нечто достаточно эфемерное, что нельзя непосредственно воплотить в артефактах системы. А ERD БД — это вполне конкретная вещь, которую можно напрямую трансформировать в SQL код создания объектов БД, можно нормализовать и т.д. А как, например, нормализовать ERD предметной области? :)))
Вроде бы всегда разделяли логическую модель данных (количество в штуках или деньгах) и физическую модель данных (количество в long или double в поле count и amount).
Понятное дело, что как программист, вы можете сразу родить анемичную свернутую модель, «интуитивно», но постулировать такой путь как «best practice» сомнительно. И проектировать от «физики» точно не есть хорошо
Типы полей в ERD БД очень часто вообще не указываются. Диаграмму надо рисовать в первую очередь для нормализации (денормализации), а типы данных для этой задачи не важны.
Схема БД (ERD) — это в первую очередь логическая структура данных, а не физическая. Вы её точно ни с чем не путаете?
Схема БД (ERD) — это в первую очередь логическая структура данных, а не физическая. Вы её точно ни с чем не путаете?
Схема БД (ERD) — это в первую очередь логическая структура данных, а не физическая. Вы её точно ни с чем не путаете?
Ключевые слова, на которые среагировал это «База данных» и ".А ERD БД — это вполне конкретная вещь, которую можно напрямую трансформировать в SQL код создания объектов БД"
Диаграмму надо рисовать в первую очередь для нормализации (денормализации), а типы данных для этой задачи не важны.
А без типов не сгенерить схему для БД и SQL для генерации. Да и нормальзация — это обычно термин из области БД.
вот и выходит что «физическая модель»
была бы приписка
Conceptual data model, Logical data model, Physical data model — не вопрос :)
:)))
Разошлись в терминологии.
Я говорил о Conceptual data model и Logical data model
То есть сперва делаем Conceptual data model, потом рисуем первую версию Logical data model (без кучи деталей), потом режем на модули, потом рисуем для каждого модуля Logical data model с большей детализацией, но всё еще без типов данных и не все поля перечислены, потом рисуем структуру классов java (то есть «натягиваем» код на схему бд, а не наоборот).
И в дальнейшем, параллельно с реализацией классов java, создаем Physical data model (sql скрипты, которые непосредственно создают таблицы, ограничения, индексы и т.д.)
Разошлись в терминологии.
Я говорил о Conceptual data model и Logical data model
То есть сперва делаем Conceptual data model, потом рисуем первую версию Logical data model (без кучи деталей), потом режем на модули, потом рисуем для каждого модуля Logical data model с большей детализацией, но всё еще без типов данных и не все поля перечислены, потом рисуем структуру классов java (то есть «натягиваем» код на схему бд, а не наоборот).
И в дальнейшем, параллельно с реализацией классов java, создаем Physical data model (sql скрипты, которые непосредственно создают таблицы, ограничения, индексы и т.д.)
Пример:
Захотели написать приложение для торговли запчастями. Делаем совсем базовый вариант.
Какие сущности будут нужны:
Товары
Покупатели
Поставщики
Места хранения
Заказы продажи
Заказы покупки
Операции с товарами — поступления, отгрузки, перемещения
Это и есть концептуальная модель данных (по крайней мере с моей точки зрения).
Предположим, порезали на модули на этом этапе.
И дальше пишем код и параллельно делаем логическую и физическую схему данных.
И тут натыкаемся на замечательную вещь. У заказа продажи есть такая особенность, что утвержденный заказ создает «резерв» товаров — уменьшает «свободный остаток» товаров на складе. А, предположим, остатки товаров и все контроли, связанные с товарами (нельзя отгрузить больше товаров, чем есть в наличии и т.п.), мы реализовали в модуле «товародвижения», а заказы продажи в модуле «продажи»…
То есть два куска очень тесно связанных данных оказались в разных модулях, что может доставить много «приятных» минут.
И на уровне концептуальной модели подобные приколы увидеть нельзя.
Захотели написать приложение для торговли запчастями. Делаем совсем базовый вариант.
Какие сущности будут нужны:
Товары
Покупатели
Поставщики
Места хранения
Заказы продажи
Заказы покупки
Операции с товарами — поступления, отгрузки, перемещения
Это и есть концептуальная модель данных (по крайней мере с моей точки зрения).
Предположим, порезали на модули на этом этапе.
И дальше пишем код и параллельно делаем логическую и физическую схему данных.
И тут натыкаемся на замечательную вещь. У заказа продажи есть такая особенность, что утвержденный заказ создает «резерв» товаров — уменьшает «свободный остаток» товаров на складе. А, предположим, остатки товаров и все контроли, связанные с товарами (нельзя отгрузить больше товаров, чем есть в наличии и т.п.), мы реализовали в модуле «товародвижения», а заказы продажи в модуле «продажи»…
То есть два куска очень тесно связанных данных оказались в разных модулях, что может доставить много «приятных» минут.
И на уровне концептуальной модели подобные приколы увидеть нельзя.
Предположим, порезали на модули на этом этапе.
И дальше пишем код и параллельно делаем логическую и физическую схему данных.
А вот это и есть проблема.
потому что получается «И тут натыкаемся на замечательную вещь. » — это значит что бизнес анализ не завершен, а архитектор не провел валидацию доменной модели/ SergeyUstinov «Это и есть концептуальная модель данных (по крайней мере с моей точки зрения). ».
Один из результатов работы архитектора — валидация целостности доменной модели, что он получил от бизнес аналитика. с точки зрения: кто делает, что делает, над чем делает и зачем делает. Роли/Системы, действия, данные и конечный результат.
То есть два куска очень тесно связанных данных оказались в разных модулях, что может доставить много «приятных» минут.
Задача архитектора грамотно «нарезать», что бы не было косяков после в разработке.
Согласен.
Я об этом и говорю — именно создание корректной и полной (но не обязательно детальной) логической модели данных (ERD) позволяет грамотно нарезать на модули систему.
До тех пор, пока не получена корректная (нормализованная) и достаточно полная схема БД — как можно говорить о корректной доменной модели?
В статье много рассуждается о структуре классов, а вот о корректной логической схеме данных — ни слова. Это часто встречается среди программистов, которые работают с ORM. Многие вообще не думают о схеме БД.
Но если для каких-то типов задач такой подход дает удовлетворительный результат, то для «учетных» систем такой подход чреват наступлением на очень серьезные грабли.
Я об этом и говорю — именно создание корректной и полной (но не обязательно детальной) логической модели данных (ERD) позволяет грамотно нарезать на модули систему.
До тех пор, пока не получена корректная (нормализованная) и достаточно полная схема БД — как можно говорить о корректной доменной модели?
В статье много рассуждается о структуре классов, а вот о корректной логической схеме данных — ни слова. Это часто встречается среди программистов, которые работают с ORM. Многие вообще не думают о схеме БД.
Но если для каких-то типов задач такой подход дает удовлетворительный результат, то для «учетных» систем такой подход чреват наступлением на очень серьезные грабли.
До тех пор, пока не получена корректная (нормализованная) и достаточно полная схема БД — как можно говорить о корректной доменной модели?
Простите, но вы путаете причину со следствием.
В начале делается доменная модель, последнее — физическая модель, в конкретном случае «схема БД»
Domain model
A domain model is a system of abstractions that describes selected aspects of a sphere of knowledge, influence or activity (a domain[3]). The model can then be used to solve problems related to that domain. The domain model is a representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software. The concepts include the data involved in the business and rules the business uses in relation to that data.
A domain model generally uses the vocabulary of the domain so that a representation of the model can be used to communicate with non-technical stakeholders.
Usage
A domain model is generally implemented as an object model within a layer that uses a lower-level layer for persistence and «publishes» an API to a higher-level layer to gain access to the data and behavior of the model.
In the Unified Modeling Language (UML), a class diagram is used to represent the domain model.
A domain model generally uses the vocabulary of the domain so that a representation of the model can be used to communicate with non-technical stakeholders.
Usage
A domain model is generally implemented as an object model within a layer that uses a lower-level layer for persistence and «publishes» an API to a higher-level layer to gain access to the data and behavior of the model.
In the Unified Modeling Language (UML), a class diagram is used to represent the domain model.
Logical data model or Logical schema
A logical data model or logical schema is a data model of a specific problem domain expressed independently of a particular database management product or storage technology (physical data model) but in terms of data structures such as relational tables and columns, object-oriented classes, or XML tags. This is as opposed to a conceptual data model, which describes the semantics of an organization without reference to technology.
Physical data model (or database design)
A physical data model (or database design) is a representation of a data design as implemented, or intended to be implemented, in a database management system. In the lifecycle of a project it typically derives from a logical data model, though it may be reverse-engineered from a given database implementation. A complete physical data model will include all the database artifacts required to create relationships between tables or to achieve performance goals, such as indexes, constraint definitions, linking tables, partitioned tables or clusters. Analysts can usually use a physical data model to calculate storage estimates; it may include specific storage allocation details for a given database system.
:)))
Правильно.
Сначала рисуем доменную модель с Conceptual data model:
А после нам надо проверить — а нет ли каких пробелов в нашей доменной модели / концептуальной схеме данных?
Для этого мы рисуем логическую схему данных в виде нормализованной ER диаграммы.
И при построении этой логической модели данных мы как раз и проверяем, нет ли ошибок в концептуальной модели данных.
И если (вернее, когда))) мы находим нестыковки — надо вернуться к доменной модели / концептуальной модели данных, и исправить допущенные ошибки.
Как вообще можно искать ошибки, не пытаясь построить нормализованную ER диаграмму?
А физическая модель — это схема БД, оптимизированная под конкретную СУБД, часто частично денормализованная и т.п.
То, что мы сначала рисуем доменную (концептуальную) модель, не значит, что мы не должны править эту модель после попытки нарисовать логическую структуру данных (нормализованную ER диаграмму).
Правильно.
Сначала рисуем доменную модель с Conceptual data model:
A domain model generally uses the vocabulary of the domain so that a representation of the model can be used to communicate with non-technical stakeholders.
А после нам надо проверить — а нет ли каких пробелов в нашей доменной модели / концептуальной схеме данных?
Для этого мы рисуем логическую схему данных в виде нормализованной ER диаграммы.
A logical data model or logical schema is a data model of a specific problem domain expressed independently of a particular database management product or storage technology (physical data model) but in terms of data structures such as relational tables and columns, object-oriented classes, or XML tags. This is as opposed to a conceptual data model, which describes the semantics of an organization without reference to technology
И при построении этой логической модели данных мы как раз и проверяем, нет ли ошибок в концептуальной модели данных.
И если (вернее, когда))) мы находим нестыковки — надо вернуться к доменной модели / концептуальной модели данных, и исправить допущенные ошибки.
Как вообще можно искать ошибки, не пытаясь построить нормализованную ER диаграмму?
А физическая модель — это схема БД, оптимизированная под конкретную СУБД, часто частично денормализованная и т.п.
То, что мы сначала рисуем доменную (концептуальную) модель, не значит, что мы не должны править эту модель после попытки нарисовать логическую структуру данных (нормализованную ER диаграмму).
То, что мы сначала рисуем доменную (концептуальную) модель, не значит, что мы не должны править эту модель после попытки нарисовать логическую структуру данных (нормализованную ER диаграмму).
Именно это и значит — не должны.
Если вынуждены «затачивать» доменную модель под физику — это не верно.
Это значит то, что доменная модель была не верна изначально!
Ну так я об этом и говорю — проблема чаще всего в неправильной доменной модели.
Если доменная модель не верна изначально — мы не сможем придумать хорошую архитектуру, и, соответственно, не сможем создать хорошую систему.
И создание логической схемы данных как раз и позволяет найти ошибки в доменной модели.
О чем статья? Создали доменную модель, на её основе выработали архитектуру приложения, но потом обнаружили, что у нас проблемы.
С моей точки зрения, причина этих проблем — неправильная доменная модель, в первую очередь в части концептуальной модели данных. И чтобы избавиться от проблем, надо найти и устранить ошибки / неточности / пробелы в доменной модели.
А как найти ошибки в схеме данных? — попробовать построить нормализованную реляционную схему данных. Теория реляционных БД как раз и разрабатывалась под такие задачи.
Схема данных — это не физика. Это именно логическая модель данных.
Если доменная модель не верна изначально — мы не сможем придумать хорошую архитектуру, и, соответственно, не сможем создать хорошую систему.
И создание логической схемы данных как раз и позволяет найти ошибки в доменной модели.
О чем статья? Создали доменную модель, на её основе выработали архитектуру приложения, но потом обнаружили, что у нас проблемы.
С моей точки зрения, причина этих проблем — неправильная доменная модель, в первую очередь в части концептуальной модели данных. И чтобы избавиться от проблем, надо найти и устранить ошибки / неточности / пробелы в доменной модели.
А как найти ошибки в схеме данных? — попробовать построить нормализованную реляционную схему данных. Теория реляционных БД как раз и разрабатывалась под такие задачи.
Схема данных — это не физика. Это именно логическая модель данных.
Схема данных БД приложения — это логическая модель системы хранения данных приложения в общем случае. Это слой(один из) абстракции между доменной моделью и их физическим хранением. Даже РСУБД имеет полное право наплевать на заданные ей логические схемы и хранить данные как ей заблагорассудится, хоть в денормализованном виде вообще, хоть в нормализованном, но по столбцам, а не по строкам — лишь бы соблюдала контракт.
С точки зрения прикладного программиста схема БД, выраженная в конкретных SQL инструкциях для СУБД — это скорее физическая модель, так как на этом уровне часто делают денормализацию. Хотя по классике это, разумеется, логическая модель, а физическую знает только СУБД.
Но удобно разделять «логическую» схему БД — нормализованную ER диаграмму, которая может не содержать многих деталей (типы полей, некоторые поля или вообще не содержать некоторых второстепенных таблиц) и «физическую» схему БД, которая уже «адаптирована» под конкретную СУБД, возможно, частично денормализована и содержит все детали.
Но удобно разделять «логическую» схему БД — нормализованную ER диаграмму, которая может не содержать многих деталей (типы полей, некоторые поля или вообще не содержать некоторых второстепенных таблиц) и «физическую» схему БД, которая уже «адаптирована» под конкретную СУБД, возможно, частично денормализована и содержит все детали.
Доменная модель в общем случае не связана со схемой БД от слова «никак». На уровне домена мы можем (или даже должны) оперировать денормалмзованными моделями, а на уровне схемы БД можем их нормализовать, и наоборот. Маппинг доменной модели на схему БД — обычно задача отдельного слоя приложения, протечки в котором чаще всего допустимы лишь во имя нефункциональных требований типа потребления ресурсов.
Для «учетных» систем корректная схема данных является критичной. И если при проработке доменной модели мы ошибемся — будут очень большие проблемы.
Я не знаю других способов проверить корректность структуры данных на уровне доменной модели, кроме как попробовать составить логическую схему данных — нормализованную ER диаграмму.
Я не знаю других способов проверить корректность структуры данных на уровне доменной модели, кроме как попробовать составить логическую схему данных — нормализованную ER диаграмму.
НЛО прилетело и опубликовало эту надпись здесь
Именно в торговле запчастями с резервами всё не так просто.
Часто есть понятие торговли «под заказ» — клиент делает заказ, и ему привозят через некоторое время (от поставщика или с другого склада).
Или например кладовщик собирает заказ и видит, что деталь бракованная, и перемещает в зону «брак». И при этом надо что то делать с заказом продажи — ведь теперь товара под него не хватает.
В одном случае, когда система начала не справляться с нагрузкой из-за блокировок, вообще пришлось создавать отдельный «микросервис» для обработки резервов. Вот здесь это обсуждали.
Часто есть понятие торговли «под заказ» — клиент делает заказ, и ему привозят через некоторое время (от поставщика или с другого склада).
Или например кладовщик собирает заказ и видит, что деталь бракованная, и перемещает в зону «брак». И при этом надо что то делать с заказом продажи — ведь теперь товара под него не хватает.
В одном случае, когда система начала не справляться с нагрузкой из-за блокировок, вообще пришлось создавать отдельный «микросервис» для обработки резервов. Вот здесь это обсуждали.
НЛО прилетело и опубликовало эту надпись здесь
Как при создании доменной модели вы проверяете, что в концептуальной модели данных (которая является составной частью доменной модели) нет существеннных ошибок или пробелов, которые в свою очередь могут привести к крупным ошибкам в архитектуре приложения?
А по поводу топика и двухфазного коммита — в обсуждении под распределенными базами подразумевается решение 1С:
Механизмы обмена данными позволяют создавать территориально распределенные информационные системы обменивающиеся данным в офф-лайн режиме, без постоянного соединения.
А по поводу топика и двухфазного коммита — в обсуждении под распределенными базами подразумевается решение 1С:
Механизмы обмена данными позволяют создавать территориально распределенные информационные системы обменивающиеся данным в офф-лайн режиме, без постоянного соединения.
Как при создании доменной модели вы проверяете, что в концептуальной модели данных (которая является составной частью доменной модели) нет существеннных ошибок или пробелов, которые в свою очередь могут привести к крупным ошибкам в архитектуре приложения?
В доменной модели ничего не проверяется, потому что это «поставновка задачи» фактически. т.е. в в номеклатуре есть имя, артикул, производитель, вес.
А что бы было еще веселее — вот вам еще куча бизнес-правил и ограничений, вроде «уникального артикула» и «цена не менее 0».
И убейтесь об стену, но ваша физика должна эти данные сохранить. и обеспечить исполнение этих правил. Как? Хотите индексы в БД стройте, хотите в бизнес-логику пихайте — это ваша проблема.
Это работа архитектора
Я под доменной моделью понимаю некую схему, которая возникает в мозгу архитектора после получения информации от заказчика. И эта схема (которая в мозгу) является исходными данными при формировании архитектуры.
Так вот, очень часто в этой схеме имеются ошибки — или бизнес аналитик и архитектор не так поняли заказчика, или заказчик сам не очень хорошо понимает, как именно должна работать система. Или заказчик просто не упомянул некоторые вещи, которые по его мнению являются не важными или само собой разумеющимися.
Причем ошибки являются правилом, а не исключением.
Хоть и написано до моего рождения, но в этой области вообще ничего не изменилось. :)))
И если архитектор не проверяет доменную модель на полноту, целостность, согласованность — он сам себе злобный буратино.
Так вот, очень часто в этой схеме имеются ошибки — или бизнес аналитик и архитектор не так поняли заказчика, или заказчик сам не очень хорошо понимает, как именно должна работать система. Или заказчик просто не упомянул некоторые вещи, которые по его мнению являются не важными или само собой разумеющимися.
Причем ошибки являются правилом, а не исключением.
Самая трудная отдельная задача в разработке программной системы — это точно решить, что разрабатывать. Ни одна другая задача работы над концепциями не является столь трудной, как разработка подробных технических требований, включая все интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим программным системам. Ни одна другая часть работы не наносит такого ущерба готовой системе, если сделана неправильно. Ни одна другая часть не исправляется позднее с бульшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками для своих клиентов, является повторяющееся получение и уточнение требований к продукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации. Даже простой ответ — «сделайте так, чтобы новая программная система работала так, как наша старая ручная система обработки информации» — оказывается в действительности слишком упрощенным. Клиенты никогда не хотят этого в точности. Более того, сложные программные системы действуют, движутся, работают. Динамику этого действия трудно себе представить. Поэтому при планировании любых действий необходимо оставить резерв для многократного взаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.
Хоть и написано до моего рождения, но в этой области вообще ничего не изменилось. :)))
И если архитектор не проверяет доменную модель на полноту, целостность, согласованность — он сам себе злобный буратино.
Более того, сложные программные системы действуют, движутся, работают. Динамику этого действия трудно себе представить.
Хоть и написано до моего рождения, но в этой области вообще ничего не изменилось. :)))
Лет эдак 25...30 назад даже UML нотация покрывали эту потребность. С тех пор появились новые нотации, новые приемы и новые инструменты, которые практически на 100% решают такие задачи, вплоть до самовалидации. на этапе рисования.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.
На моей памяти, нормально сделанные проекты при соблюдении методологии таких проблем не было. Сдавались с первого раза и шли в работу, как минимум 5 проектов с более чем годовым циклом (для примерной оценки объема)
На моей памяти, нормально сделанные проекты при соблюдении методологии таких проблем не было. Сдавались с первого раза и шли в работу, как минимум 5 проектов с более чем годовым циклом (для примерной оценки объема)
Какой методологии? Водопада?
Какой методологии? Водопада?
От проектной метологии не зависит. И водопад тоже был и Scrum.
Ну что тут сказать — круто! Совсем как Слепаков спел. :)))
Ведь у меня и всех моих знакомых такие проблемы были…
Иногда больше, иногда меньше — но на всех проектах.
Ведь у меня и всех моих знакомых такие проблемы были…
Иногда больше, иногда меньше — но на всех проектах.
Лет эдак 25...30 назад даже UML нотация покрывали эту потребность. С тех пор появились новые нотации, новые приемы и новые инструменты, которые практически на 100% решают такие задачи, вплоть до самовалидации. на этапе рисования.
???
Ваши клиенты хорошо знают UML и новые нотации / инструменты? И с их помощью тот же начальник отдела логистики, например, легко может себе представить алгоритм построения маршрута?
И например все эти команды, которые уже более 10 лет разрабатывают автопилот (всягие гуглы и апплы) — просто не в курсе этих новых инструментов, раз не могут легко представить себе, как именно автопилот должен работать? :)))
Ваши клиенты хорошо знают UML и новые нотации / инструменты? И с их помощью тот же начальник отдела логистики, например,
легко может себе представить алгоритм построения маршрута?
Я вас удивлю, наверное, но 10....20 минут достаточно что бы «начальник отдела логистики» вполне мог обсуждать и проводить review представленных диаграмм процессов и моделей данных. Примените корретную мотивацию :)
Другое дело, что можно проверить логическую согласованность вроде требуется артикул номеклатуры в одной сущности, но нету ни в справочниках, ни бизнес правили, ни ограничений, ни участников ответсвенных за эту часть.
Но в процессе приведения доменной модели в адекватное состояние это всплывает.
Это зависит от того как проводится бизнес-анализ, какая нотация какой инструмент.
Но в процессе приведения доменной модели в адекватное состояние это всплывает.
Это зависит от того как проводится бизнес-анализ, какая нотация какой инструмент.
Другое дело, что можно проверить логическую согласованность вроде требуется артикул номеклатуры в одной сущности, но нету ни в справочниках, ни бизнес правили, ни ограничений, ни участников ответсвенных за эту часть.
Но в процессе приведения доменной модели в адекватное состояние это всплывает.
Это зависит от того как проводится бизнес-анализ, какая нотация какой инструмент.
Создание нормализованной ER диаграммы как раз и является, по моему мнению, хорошим инструментом для поиска неувязок в концептуальной схеме данных и в целом в доменной модели.
Правда, это хорошо работает только при создании «учетных» систем, при создании приложений другого типа этот инструмент не очень полезен.
Создание нормализованной ER диаграммы как раз и является, по моему мнению, хорошим инструментом для поиска неувязок в концептуальной схеме данных и в целом в доменной модели.
В общем да.
BA в принципе в три стадии проходит: запись «потока сознания», свертка модели данных/очистка от противоречивых данных, рефакторинг (если требуется изменение существующей системы).
Правда, это хорошо работает только при создании «учетных» систем, при создании приложений другого типа этот инструмент не очень полезен.
Абсолютно без разницы — результат одинаков и не зависит от приложения если соблюдается методология.
Такие приколы сложно увидеть на любом уровне если не знать куда смотреть.
Схема БД — не логическая структура данных, а структура хранения данных.
Я вас огорчу, но вы пока занимаетесь детскими задачами. Откройте например постановление 354 по расчету платы за коммуналку и запроектируйте.
А какой фреймворк возьмем? Если немного погуглить, то станет понятно, что особо вариантов нет, мы будем делать на Spring Framework. Причина проста, в Spring Cloud есть все, что нам потребуется.
Да ладно? http://www.gajotres.net/best-available-java-restful-micro-frameworks/. Выбор более чем есть. Я не особо вкурсах, но Spring Cloud же правда не tomcat использует?
Для тех, кто думает что нет, что язык программирования второстепенен и вообще, важна только команда, я предлагаю провести маленький мысленный эксперимент. Подумайте, на каком языке вы бы такой проект точно не делали, т.е. считаете, что это было бы однозначно неправильное решение. А теперь представьте себе, что архитектор решил таки сделать проект именно на этом языке. А когда вы будете гневно возмущаться, он вам скажет: это второстепенный вопрос, главное команда!
Потому что заставлять писать команду на языке, который она не знает довольно глупо, нет? Но такого языка нет, все решается затратами и неудобством. Если нужно писать на haskell и мне объяснят, почему именно на нем (скажем, какая-то важная либа есть только под него) то так и быть. Почему нет?
А можно и по другому. При старте каждый сервис должен постучаться к VehicleTypesService сообщить ему о своем существовании. Это решение вроде хорошо выглядит, но не отвечает на вопрос что делать, если нам надо не добавить, а удалить вид транспортного средства.
В моем решении микросервисы которые должны предоставлять метаинформацию о своих услугах создают в шине обмена inbox с определенным именем при запросе на который отдают эту самую информацию. В итоге, тот кому информация нужна делает RequestMany в этот inbox и получает актуальную на текущий момент информацию.
А если актуальность важна, но не сильно? Например, выбор способа отправки поздравления друга с днём рождения за несколько часов до его наступления, с учётом условий типа «предпочтительнее емэйл, но если на момент отправки он будет лежать, то отправить смс, а если лежит прямо сейчас и время отправки в сла не укладывается, то мыло не предлагать»
То что вы описали это уже заданный сценарий работы, а то что описывал я это скорее момент создания этого сценария. Т.е. захожу в какую-то консоль, она делает запрос и говорит, что доступны для доставки сервисы — СМС-доставки, почтовой доставки, телеграмм. Я указываю сценарий, доставить по мейлу, но если не получается то через СМС. Соответсвенно если СМС сервис отключен, то смогу выбрать только почту. Т.к. отключение сервиса это аварийная ситуация, которая не должна длиться долго, то не вижу смысла закладываться на нее и хранить список сервисов где то в базе.
>единая точка входа, он же API Gateway
>поиск сервисов, он же Service Discovery
>одна точка конфигурации, он же Config Service
>центральная точка сбора и анализа логов
>мониторинг
И в итоге мы получаем… получаем… ну например полноценную реализацию OSGI. Где микросервисы — вовсе не автономные непонятно какие процессы, а управляемые объекты в управляемой среде, где есть и поиск/дискавери, и сбор/анализ логов, и мониторинг, и конфигурация, и многое другое.
>поиск сервисов, он же Service Discovery
>одна точка конфигурации, он же Config Service
>центральная точка сбора и анализа логов
>мониторинг
И в итоге мы получаем… получаем… ну например полноценную реализацию OSGI. Где микросервисы — вовсе не автономные непонятно какие процессы, а управляемые объекты в управляемой среде, где есть и поиск/дискавери, и сбор/анализ логов, и мониторинг, и конфигурация, и многое другое.
>поиск сервисов, он же Service Discovery
UDDI?
НЛО прилетело и опубликовало эту надпись здесь
Внимательно прочел, нашел одну принципиальную ошибку — что мешает разным сервисам пользоваться одной (ОК, физически разными, но реплицируемыми или federated) базами данных? Ответ: ничто не мешает.
Сервис — это превращатель request в response. Какую он там БД использует — исключительно его дело, не так ли?
Сервис — это превращатель request в response. Какую он там БД использует — исключительно его дело, не так ли?
и в какой-то момент вы получаете на одну БД десяток сервисов использующих некую таблицу N для своих нужд и не только читающих из неё, но и пишущих. А завтра вам надо в эту таблицу для сервиса K добавить колонку с NOT_NULL флагом.
Что будем делать?
Определение мешает :) Превращатель запроса в ответ — это интерфейс, контракт. Сервис отвечает за то каким ответ будет не на время жизни цикла запрос-ответ, а за всё время своего существования. Если априори ответ зависит только от состояния другого сервиса, то это лишь другой интерфейс к данным. Если от нескольких — то это сервис агрегации
Весьма интересно! С удовольствием подожду продолжения!
...умл диаграмки можно и наряднее, красивенько чтоб
А что автор еще пореккомендует почитать/посмотреть по архитектуре микросервисов, очень инетересует практический вопрос authorisation and authentication?
Я бы порекомендовал основательно покопаться на этом сайте(Обратите внимание на комменты, бывают очень интересно):
http://microservices.io/index.html
По поводу Security. У Spring'а есть Spring Security. Но вообще лично я очень трепетно отношусь к таким вещам, ибо понимаю я в них не много, а потенциальный ущерб от них огромен. Для меня это примерно как дать студенту программировать софт для космических ракет. Он(студент) наверное таки что то сделает и это будет даже работать, но однажды вся эта штука взорвется красивым феерверком и уничтожит всю вашу работу. Поэтому я иду к спецам и спрашиваю, что и как делать. IMHO конечно.
http://microservices.io/index.html
По поводу Security. У Spring'а есть Spring Security. Но вообще лично я очень трепетно отношусь к таким вещам, ибо понимаю я в них не много, а потенциальный ущерб от них огромен. Для меня это примерно как дать студенту программировать софт для космических ракет. Он(студент) наверное таки что то сделает и это будет даже работать, но однажды вся эта штука взорвется красивым феерверком и уничтожит всю вашу работу. Поэтому я иду к спецам и спрашиваю, что и как делать. IMHO конечно.
Но в данном случае мы все эти этапы пропустим, т.к. практически все поднятые в этой статье вопросы возникнут в любом случае, независимо от выбранной методологии.
Не согласен с этим пунктом.
Есть много ситуации когда важно получить отклик и это влияет на архитектуру.
Или важно понять приоритеты задач.
Далее этот пункт также порождает выбор языка, фреймворка, технологий.
Серебренной пули не существует ;) Каждый изобретает свой велосипед подход, к достижению им же самим заданной планки перфекционизма. Всегда интересно сравнить свой и чужой опыт в этом процессе.
Ждем продолжения!
Ждем продолжения!
А у меня еще вопрос: вы про системного архитектора или программного архитектора?
Спасибо за статью
Но судя по заголоку:
Это вопрос должен решать архитектор. Или нет?
и началу статьи:
Мы увидим,… и зададимся вопросом, должен ли в данном случае принимать решение архитектор или разработчик может решить эту проблему сам.
ожидал в статье больше выводов, в стиле: Да, это должен решить программист, а это архитектор.
Спасибо! Ждем продолжения.
Привет,
статья интересная. Сразу видна ищущая душа и хороший опыт в разработке.
Для полного ответа нужно писать хорошую статью. Попробую сделать это к/за выходные.
Если же коротко (дальше будет критика и помидоры), то статья написана программистом, хорошим Lead разработчиком, но еще не архитектором.
Было принято вагон решений, практически в каждом абзаце, но они необоснованны. Но я даже больше больше скажу: их невозможно обосновать в данных условиях.
Почему? Нету требований. Особенно нефункциональных (те самые Quality Attributes: https://msdn.microsoft.com/en-us/library/ee658094.aspx).
Без нефункциональных требований (NFR) практически любая архитектура подойдет для озвученной задачи.
С точки зрения снижения стоимости: девушка на телефоне с журналом заявок (даже не экселькой) подходит. Вот и Solution. Забирай, мне не жалко.
Косвенно про NFR было сказано только в секции «Добавление нового типа транспорта в систему». Quality Attribute (QA) называет Modifiability. Рассмотрены два варианта: Runtime configuration и Development. Вариантов намного больше: https://image.slidesharecdn.com/sap3chapter7-140630124448-phpapp02/95/software-architecture-in-practice-chapter-7-4-638.jpg (картинка из Software Architecture in Practice. Обратите внимание на Artifacts (это то, что меняется) и Environment (это когда меняется).
Так же упоминается выбор языка программирования (Conceptual Integrity, Maintainability, Reusability), Отказоустойчивость (Availability и Reliability), мониторинг и логирование (Supportability),… Но без конкретики работать с этим нельзя.
Второй момент — непонятно как вы будете зарабатывать деньги, а если уйти от денег, то как конкретно вы будете приносить пользу клиентам. Т.е. нет описания, хоть поверхностного, бизнесс модели. Без этого есть только система (неважно насколько хорошая), в которую вложили кучу бабла, но еще не поняли как зарабатывать на ней.
Если коротко (еще короче чем выше):
Когда будешь задумываться о нефункциональных требованиях — станешь на путь к System Architect-ору.
Когда будешь задумываться о бизнесе и пользе клиентам — станешь на путь к Solution Architect-ору.
Литература для расширения сознания:
Книга Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives-ebook/dp/B0061LAKW0
В ней про NFR и работу с бизнесом.
Видео: Евгений Кривошеев — Как не угробить архитектуру сразу же https://www.youtube.com/watch?v=_Kex5hwGE-w
В ней как раз о решениях, которые принимает архитектор. Очень доступно.
Видео: Who is solution architect? — Architecture Community Gomel https://www.youtube.com/watch?v=oNFGvEiPFoU
Моя презентация про Solution Architect. В ней тоже про решения и роль архитектора на проекте.
статья интересная. Сразу видна ищущая душа и хороший опыт в разработке.
Для полного ответа нужно писать хорошую статью. Попробую сделать это к/за выходные.
Если же коротко (дальше будет критика и помидоры), то статья написана программистом, хорошим Lead разработчиком, но еще не архитектором.
Было принято вагон решений, практически в каждом абзаце, но они необоснованны. Но я даже больше больше скажу: их невозможно обосновать в данных условиях.
Почему? Нету требований. Особенно нефункциональных (те самые Quality Attributes: https://msdn.microsoft.com/en-us/library/ee658094.aspx).
Без нефункциональных требований (NFR) практически любая архитектура подойдет для озвученной задачи.
С точки зрения снижения стоимости: девушка на телефоне с журналом заявок (даже не экселькой) подходит. Вот и Solution. Забирай, мне не жалко.
Косвенно про NFR было сказано только в секции «Добавление нового типа транспорта в систему». Quality Attribute (QA) называет Modifiability. Рассмотрены два варианта: Runtime configuration и Development. Вариантов намного больше: https://image.slidesharecdn.com/sap3chapter7-140630124448-phpapp02/95/software-architecture-in-practice-chapter-7-4-638.jpg (картинка из Software Architecture in Practice. Обратите внимание на Artifacts (это то, что меняется) и Environment (это когда меняется).
Так же упоминается выбор языка программирования (Conceptual Integrity, Maintainability, Reusability), Отказоустойчивость (Availability и Reliability), мониторинг и логирование (Supportability),… Но без конкретики работать с этим нельзя.
Второй момент — непонятно как вы будете зарабатывать деньги, а если уйти от денег, то как конкретно вы будете приносить пользу клиентам. Т.е. нет описания, хоть поверхностного, бизнесс модели. Без этого есть только система (неважно насколько хорошая), в которую вложили кучу бабла, но еще не поняли как зарабатывать на ней.
Если коротко (еще короче чем выше):
Когда будешь задумываться о нефункциональных требованиях — станешь на путь к System Architect-ору.
Когда будешь задумываться о бизнесе и пользе клиентам — станешь на путь к Solution Architect-ору.
Литература для расширения сознания:
Книга Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives-ebook/dp/B0061LAKW0
В ней про NFR и работу с бизнесом.
Видео: Евгений Кривошеев — Как не угробить архитектуру сразу же https://www.youtube.com/watch?v=_Kex5hwGE-w
В ней как раз о решениях, которые принимает архитектор. Очень доступно.
Видео: Who is solution architect? — Architecture Community Gomel https://www.youtube.com/watch?v=oNFGvEiPFoU
Моя презентация про Solution Architect. В ней тоже про решения и роль архитектора на проекте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Это вопрос должен решать архитектор. Или нет?