Pull to refresh

Comments 54

Когда вы называете структуры данных “моделью домена”, вы вольно или нет подменяете понятия.

Um, no. Тут вся разница только в том, что «домен» в данном случае — это не домен всего приложения в целом.
Доменная модель имеет смысл только с уточнением — а про какой же конкретно домен мы вообще говорим? Про всё приложение? Про отдельную подсистему? Про что-то еще?

У фронтэндщика, пилящего отдельную красивую кнопочку — тоже есть своя доменная модель. Для кнопочки.
Спасибо за обратную связь. А можете привести примеры доменов в вашем понимании?

Я например выделяю такие домены (предметные области):
— Shipping (Перевозка грузов)
— Banking (Банковские услуги)
— Booking (Продажа билетов)
А можете привести примеры доменов в вашем понимании?

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

Как только вы можете выделить подсистему в вашей системе — вы сразу же можете выделить и домен для неё.
Ну можно же привести пример «предметной области» для человека пилящего кнопочку или UI компонент?

К примеру если вы разрабатываете ядро библиотеки `React` (или реализуете компонент Button в ядре этой библиотеки) предметной областью для вас будет:
— UI библиотеки для Web

Но если вы на базе `React`рисуете кнопку «Снять наличные», для банковского приложения. Это домен «Banking», и вы как фронэндщик пользуетесь моделью доменного уровня через API. И это не зависит не от масштаба, не от точки зрения.

Так же, если вы разрабатываете iOS, предметная область будет:
— Операционные системы для мобильных платформ

Но если вы решаете с помощью компьютера бизнес-задачи, домен будет отражать бизнес функции.
Но если вы на базе `React`рисуете кнопку «Снять наличные», для банковского приложения.

Конечно. Я так и написал, «зависит от масштаба и точки зрения». Если вы пилите кнопку с логикой для банковского приложения, имея в виду именно полную реализацию процедуры «снятие наличных» — вы работаете в доменной модели банковских услуг. Если вы пилите эту кнопку, но у вас просто есть ТЗ, что и как должно быть дёрнуто на бекэнде при нажатии на эту кнопку — вы работаете в доменной модели фронтэнда, дергающего API (впрочем, иметь в виду доменную модель верхнего уровня тут тоже бы неплохо). А если вы пилите кастомную кнопку, которая потом будет использоваться в том числе и в контексте снятия наличных — вам довольно сильно пофиг на доменную модель верхнего уровня (но скорее всего ТЗ на фичи для вашей кнопки вы сформулируете именно оттуда), у вас просто кнопка.
Если вы пилите кнопку с логикой для банковского приложения, имея в виду именно полную реализацию процедуры «снятие наличных»

Нет, реализацию процедуры «снятие наличных» я не имел ввиду.Я считаю эту процедуру всего лишь часть предметной области «Банкинг».

вы работаете в доменной модели фронтэнда, дергающего API

Правильно ли я понимаю, что предметная область в данном случае:
— Фронтэнд дергающий API

А если вы пилите кастомную кнопку, которая потом будет использоваться в том числе и в контексте снятия наличных — вам вообще пофиг на доменную модель верхнего уровня...

Вы правы. В данном случае вас как разработчика интерфейса доменная модель не интересует. Только не могу понять, чем отличается доменная модель верхнего уровня и нижнего уровня? Можете раскрыть данные определения? Или дать хотя бы ссылки где можно об этом почитать?
Я всегда видел это совершенно иначе.
В концептуальной модели данных не идет речи ни о каких БД или АПИ. Это совершенно абстрактная вещь, описывающая предметную область конкретного предприятия. А каждая из 100500 информационных систем предприятия имплементирует у себя какую-то проекцию этой модели.
Это единое формализованное описание, которое ближе к бизнесу, чем к ИТ. Поэтому его можно подавать на вход в каждую новую внедряемую на предприятии систему и избегать того, что АБС и CRM у вас оперируют объектами, которые вообще друг на друга никак не мапятся.
Т.е. концептуальная модель — это такой своеобразный объемный многогранник. Вокруг него под разными углами расположены плоскости — информационные системы. И проекции многогранника на эти плоскости — объектные модели этих систем.
Это единое формализованное описание, которое ближе к бизнесу, чем к ИТ.

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


Мне очень понравилась ваше разделение на "концептуальную модель данных" и "проекции концептуальной модели данных для конкретной ИС", но я так вижу, что двигаться она должна не от концепта к проекциям, а от проекций к концепту.

Возможно, где-то в большом бизнесе, есть подобные формализованные описания. Но для этого в большом бизнесе должен быть специальный человек-агрегатор, который создаёт эти описания для бизнеса.

Этот человек — энтерпрайз архитектор. Только создает он их не для бизнеса, а как раз от бизнеса для ИТ.
я так вижу, что двигаться она должна не от концепта к проекциям, а от проекций к концепту.
Тогда в ней не будет никакого практического смысла. Концептуальная модель предметной области — это инструмент, который позволяет поддерживать всю инфраструктуру компании в едином ± виде. Начиная новое внедрение архитектор решения получает на вход не только требования от бизнеса, но и концептуальную модель от архитектора предприятия. А потом согласует с ним свою можель данных. Или как минмум ту ее часть, которая может смотреть наружу. Однажды мне сразу выдали библиотеку классов для сериализации/десериализации, котороя я должен был пользоваться для интераций — генериалсь она автоматичеси на основе как раз концептуальной модели, распростарнялась между разными системами и периодически обновлялась.
Я чаще сталкивался с ситуациями, когда есть данные, которые хранятся в различных репозиториях (БД, файлы, документы), и которые по факту отражают отдельные проекции концептуальной модели данных, которая нигде и никем не зафиксирована.

Все так, увы. Буквально 2 раза встречал у заказчика энтерпрайз архитектора. Оба раза в международных компаниях. В остальных случаях просто зоопарк IT-систем, которые растут совершенно бесконтрольно. Тем не менее правильный путь именно от концептуальной модели к частной.
Не корректно называть «данные» моделью предметной области.
Проблема в том, что эта часть модели как раз наиболее статична и наиболее зависима от предметной области. Поведение, напротив, может состоять из алгоритмов, которые: 1. Зависят от конкретных выбранных методов решения задач а не от выбранной предметной области в целом. 2. Могут относиться скорее к математике или чему-то другому очень абстрактному, чем к предметной области.
Эти алгоритмы можно реализовать как набор классов, функционально или процедурно.
Завтра мы решим решать задачи глубже или детальнее и алгоритмы (классы, функции или процедуры) будут заменены совершенно другими. При этом, модель данных не поменяется т.к. это вся та же предметная область. Получается, мы поменяли доменную модель? Тогда в чем заключалась ее «доменность»?
Модель предметной области — это концептуальная модель, которая включает в себя как поведение, так и данные. Она может быть инкапсулирована в отдельный слой, а может быть размазана по всему приложению.
Допустим, мы описали те самые доменные объекты, которые содержат данные и описывают состояние предметной области. В идеальном случае доменное поведение может быть реализовано непосредственно в методах этих объектов. Но мне кажется, это возможно только в очень простых задачах. Можно собрать поведение в процедуры, но такой код сложно переиспользовать, тестировать или понимать. Можно реализовать поведение в виде множества «менеджеров» с довольно абстрактным и далеким от предметной области назначением, которые тем не менее будут хорошо переиспользоваться в будущих версиях и инкапсулировать промежуточные результаты и детали поведения. Там где работа с промежуточными данными не сложна менеджеры превратятся просто в static функции. Эти менеджеры и static функции никак не являются доменными сущностями, но содержат все поведение. Не это ли как раз и называют «анемичной моделью»?
“Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению
Процедурный подход, это когда разрабатывая процедуру мы никак не ограничиваем себя в том, какие данные она использует или поменяет и поэтому эту процедуру очень сложно использовать еще раз в другой задаче, тестировать и разобраться что же она в точности делает. Поведение как раз в процедурах концентрируется очень хорошо и понятно (есть такая старая идея — структурное программирование). Напротив, ООП подразумевает размазывание поведения по методам всех объектов, когда нечто главное всегда происходит в другом месте кода, где ни посмотри. Анемичная модель позволяет сконцентрировать поведение в неких объектах, которые оперируют не своими данными. Поэтому смысл вашего утверждения ускользает.
Если работа с данными из одних объектов происходит в других, это говорит лишь о проблемах в проектировании

> Но мне кажется, это возможно только в очень простых задачах

Обычно к такому заключению приходят когда из rich domain model уходят в другую крайность и они становятся огромные и непонятные, от того что в них помещается куча несвязанной логики и пара десятков полей.

> Допустим, мы описали те самые доменные объекты, которые содержат данные и описывают состояние предметной области

Объекты без поведения это просто структуры данных, они не описывают ограничения предметной области.
Чаще всего они описывают лишь какие поля вместе во вьюшке отображаются, и пока декомпозиция делается через UI, о грамотном проектировании объектов речи не идёт.
И да, анемичные модели первое время позволяют скрывать эти проблемы.
Если работа с данными из одних объектов происходит в других, это говорит лишь о проблемах в проектировании
Допустим, предметная область — это некие физические объекты с множеством свойств и некие события, которые с этими объектами происходят. Дальше, программа получает запрос, выполняет анализ этой модели и возвращает ответ. Алгоритм этого анализа сложен. Даже в лоб процедурно его может реализовать только очень хороший программист. Алгоритм удобно описать в стиле ФП (на входе вся модель и запрос, на выходе результат), или в виде нескольких объектов-модулей, каждый из которых выполняет часть работы. Эти объекты-модули будут работать с данными о физических объектах и событиях. Т.е. не со своими данными. Значит это ошибка проектирования. Как ее решить? И главное, зачем ее решать?
Объекты без поведения это просто структуры данных, они не описывают ограничения предметной области.
У предметной области может не быть никаких стабильных ограничений, кроме тех которые уже заложены самой структурой классов. Все дополнительные ограничения могут зависеть от того, какая задача сейчас решается. Что физически может происходить в предметной области, а что нет? Если пользователь вводит данные, которые выглядят некорректно, нужно запретить ввод таких данных или только предупредить пользователя, пояснив что он скорее всего делает не так? Ответы на эти вопросы могут меняться в разных версиях продукта или при решении разных задач. Тогда какой смысл жестко связывать ограничения на данные с самими данными?
Чаще всего они описывают лишь какие поля вместе во вьюшке отображаются, и пока декомпозиция делается через UI, о грамотном проектировании объектов речи не идёт.
В моем случае, они описывают (моделируют) нечто реально существующее в мире (объекты, события с объектами), как оно есть, независимо от UI.
У Вас в начале статьи ссылка на сайт Slack. Это, как я понимаю, типа социальной сети что-то. Я там зарегистрировался, но всё равно пройти по ссылкам не могу. Это какой-то закрытый сайт? Зачем тогда ссылки в статье?
Это чат. По сути комьюнити. Оно открыто, но специфиика Слэка в том что надо зарегестрироваться, после чего поставить приложений и войти. Ссылка в Slack добавлена на случай, если вдруг кто-нибудь из сообщества решит проверить, что цитаты не искажены и слова не переиначены :)

Я в вашей статье нашёл для себя ещё одно подтверждение тому, что данные нужно отделять от бизнес-логики. Вы пишете:


“Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению

Но на это можно посмотреть и так, что в приложении есть чисто данные — данные без поведения, а есть слой кода, который имплементирует бизнес-логику, которая оперирует данными так или иначе. И этот слой может быть создан как в процедурном стиле, так и в объектно-ориентированном. Таже можно размазать этот слой по всему приложению или сконцентрировать в отдельные группы (controllers, helpers, services).


В таком случае мы в рамках одного приложения получаем то, о чём коллега lohmatii чуть выше говорил, как о "концептуальной модели данных" конкретного предприятия в рамках "большого бизнеса". Только тут мы имеем дело с "концептуальной моделью данных отдельного приложения" — она может быть формализована (сохранена в конкретной структуре в БД или файлах), а её проекции использоваться отдельными бизнес-функциями (процедурными или ОО). Хоть той же кнопкой "Снять наличные", если эта кнопка хоть что-то использует из "концептуальной модели данных приложения" (что маловероятно).

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

Именно. Основная моя мысль заключается в том, что по сути «модель предметной области» во первых сосоит из данных и поведения (не важно, они вместе или нет), а во вторую, определяется в первую очередь поведением. Если вы отделите данные и не будете реализовавать «бизнес-логику» как набор классов, модель предметной области ни куда не денется. Даже в случае если вы растащите логику по разным «инфраструктурным сущностям». Она будет существовать, просто в неявном виде (внутри инфраструктурного кода).

“Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению

Это к слову мой перевод вот этого предложения из статьи Фаулера про анемичную модель:
The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk.

Модель бизнес логики это в первую очередь поведение. Бизнесу нет дела какие вы данные туда-сюда гоняете

“Архитектура с анемичной моделью” не что иное как процедурный подход к созданию архитектуры приложений в котором модель предметной области размазана по всему приложению

В моём текущем проекте используется анемичная модель предметной области, но при этом вся бизнес-логика собрана в одном слое. Так что «модель предметной области размазана по всему приложению» — это не про анемичную модель, вещи ортогональные.
И во фразе Фаулера, которую Вы как бы перевели, об этом ни слова.
но при этом вся бизнес-логика собрана в одном слое

Этот слой по сути и есть ваша «модель предметной области». Не данные которыми вы оперируете, а поведение. Ваша анемичная модель — статическая структура не имеющая для бизнеса ни какой ценности сама по себе и не выполняющая никакой работы. Это просто «данные».
Да я вообще не об этом. Я о том, что анемичная модель, это обязательно «размазано по всему приложению» — это неправда. Можно размазать и анемичную модель, и богатую; и ту, и другую можно собрать в одном месте. Так что включать данное утверждение в определение анемичной модели не стоит.
И это никак не зависит от того, что понимается под моделью предметной области — только данные, только поведение или их совокупность.
Анемичная модель не контролирует консистентность своего состояния, и контроль за консистентностью утекает в клиентский код, отсюда и «размазывание» БЛ.
Туда же проблемы с тестируемостью и связностью.
Почему не контролирует? То, что поведение и состояние хранятся в разных классах, не означает, что поведение не может контролировать состояние.
Клиентский код вообще не должен заниматься такими вещами, как консистентность бизнес-данных, вся работа с предметной областью собрана в одном месте и доступна наружу через контракты/API. А как уж она там внутри устроена — богатая модель или анемичная — это вопрос другой, как я уже говорил выше — ортогональный «размазанности» или «скучкованности».
Повторюсь ещё раз — в моём текущем проекте используется анемичная модель предметной области (такая архитектура от предков досталась), но при этом вся бизнес-логика собрана в одном месте, а не размазана по всей системе.
Почему не контролирует? То, что поведение и состояние хранятся в разных классах, не означает, что поведение не может контролировать состояние.

Так ведь в том и дело что контроллировать состояние приходится клиентскому коду, поведению описываемому в других классах, самое худшее что мне приходится видеть — прогон модели через валидатор перед сохранением, т.к. мы просто уже не можем ей доверять. И это, к сожалению, до сих пор вполне практикуется.

вся работа с предметной областью собрана в одном месте и доступна наружу через контракты/API. А как уж она там внутри устроена — богатая модель или анемичная — это вопрос другой, как я уже говорил выше — ортогональный «размазанности» или «скучкованности».

Тогда у меня вопрос что вы называете анемичной моделью, потому что в текущем контексте я ей зову просто структуру кладущуюся в базу в виде полей+геттеров+сеттеров
Прощу прощения за долгую задержку, на работе аврал :(
Тогда у меня вопрос что вы называете анемичной моделью, потому что в текущем контексте я ей зову просто структуру кладущуюся в базу в виде полей+геттеров+сеттеров

Анемичная модель предметной области — это классы-модели без поведения и классы-сервисы без состояния. Если сильно огрублять, то в богатой модели каждой бизнес-сущности соответствует один класс, а в анемичной — два, модель и сервис.
Так ведь в том и дело что контроллировать состояние приходится клиентскому коду,

Состояние контролируют сервисы, которые являются частью модели предметной области и, соответственно, не являются клиентским кодом.

Логика отдельно, данные отдельно это старый добрый процедурный код, добавление классов не делает его ОО.


Где вы нашли подтверждение верности подхода с анемичными моделями — ума не приложу.

Это совершенно не значит что код «процедурный». В функциональном программировании логика и данные всегда идут раздельно. Физически их можно запихать в один класс, но смысла в этом особого нет, т.к. все объекты этого класса неизменяемы.

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

Автор как-будто сам себя пытается убедить.

Да нет, я убежден в том, что бизнес-логику реально выделить в отдельный слой и имел возможность сделать это на практике. Я это проверял, это работает.

Нет никаких полностью абстрактных бизнес-логик.

Вы правы, бизнес-логика той или иной предметной области вполне конкретна. Я и не говорю про существование «абстрактных бизнес логик». Я просто говорю об общих принципах.

Если между хранилищем и бизнес логикой сделать очень хорошую изоляция в 99% это будет тормозить, т.к. вы не сможете использовать фичи хранилища или ваше приложение будет немасштабируемое. Нельзя всё взять и поделить.

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

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

Всегда нужно думать.

Абсолютно с вами согласен, именно поэтому я и делюсь мыслями, чтобы еще раз подумать самому и дать подумать другим.
Kubernetes пример хороший, но немногочисленный и глядя на то, насколько его сложно использовать с нуля — я думаю там очень сильно потеряна связь с реальностью. Там больше диктат программного и аппаратного обеспечения, чем хотелок администратора.

Тут действительно нужно соблюдать баланс. Я это и имел в виду, что почти никогда не получится бизнес логику полностью абстаргировать от всего. Хотя стремиться к изоляции, конечно, нужно.
Причина почему НЕ надо хранить бизнес логику внутри модели, заключается в том, что эта самая логика сильно варьируется в разных сценариях (use cases), число и вариативность которых невозможно предсказать (если, конечно, у вас не “водопад”). Например, есть модель “Пользователь”: {id, login, name}. Субъект “Пользователь” может поменять только “name”, субъект “Администратор”, может поменять еще и “login”, но только в том случае если он уникальный, а какая-нибудь утилита интеграции может менять вообще все.
В модели должны быть представлены только абсолютные ограничения, которые в 99% случаев выражаются в виде отношений между моделями и типов атрибутов.
То что вы вкладываете в понятие «модель», называется «модель данных».
То что выражено в коде как UseCases, является частью «модели предметной области».

Все эти концепции давно подробно описаны. Статья является попыткой донести до коллег по цеху важность понимания этих самых концепций. Другими словами я хочу сказать следующее: — Не нужно изобретать велосипеды, и вкладывать в данные концепции свой смысл. Он давно вложен и подробно описан. Все что нужно сделать, это изучить их и пользуясь своей головой применять на практике, там где это необходимо.
У коллег по цеху уже сложилась четкая ассоциация, что модель — это в первую очередь модель данных. “Модель предметной области” это настолько размытое понятие, что вряд ли ему можно найти значимое практическое применение.

Если разделять "модель данных" и "модель предметной области", то тогда нужно чётко фиксировать границы этой самой "предметной области" (границы применимости моделей). Я также допускаю, что в рамках одного приложения с одной моделью данных могут работать различные модели предметной области. В зависимости от того в какой проекции обрабатываются элементы этой модели данных (UI, API, validation, ACL verification, business processing). Например, грид на UI'е может работать с моделью предметной области "User Interface" (строки-столбцы), являющейся комбинацией различных элементов модели данных (номер заказа, имя клиента, ...). По большому счёту, гриду всё равно, из каких источников поднимаются в него данные (БД, файлы, внешний запрос), в его мире (области) все предметы — это строки, столбцы, рендереры, валидаторы, фильтры и т.п. Допустим, мы подтягиваем в своё приложение библиотеку/модуль для построения гридов, тогда мы должны имеющиеся в проекте данные представлять в виде, понятном для соответствующей предметной области (гридов). Получается, что у нас приложение разделяется на некоторое кол-во областей (представление данных, ввод-вывод, верификация, обработка, хранение, выборка) между которыми данные дрейфуют, преобразовываясь из одной структуры в другую. Да, кстати, и моделей данных у нас может быть множество. По большому счёту, для каждого внешнего приложения, с которым наше обменивается данными, присутствует своя "модель данных". И мы опять должны реструктурировать данные при передаче/получении в/из внешнего приложения из нашей структуры (наша модель данных о Клиенте) в структуру, понимаемую внешним приложением (их модель данных о Клиенте).


Это так, мысли вслух, чтобы ещё больше запутаться самому и запутать остальных.

Мне кажется что здесь вы слегка искажаете понятие «Предметная область».
«User Interface» — как мне кажется не является предметной областью до тех пор пока вы не разрабатываете UI библиотеки и/или фреймворки.

Грубо говоря, если вы разрабатываете приложение для «Банкинга», ваша предметная область: «Банкинг». Модель в этом случае реализована только на сервере. UI всего лишь рендерит результаты модели которые приходят в «удобном виде» через API. Вы всего лишь используете UI библиотеку чтобы построить UI банковского приложения.

Предметная область (домен) — это всегда о том, какую вы проблему пытаетесь решить разрабатывая приложение в целом (Нужно задать вопросы: Зачем я пишу эту программу? Кому она поможет? Для какой она сферы? Это и есть предметная область.).

Когда вы разрабатываете приложение для банкинга, вы не решаете проблему изобретения UI компонентов. То как реализован UI, как он рендерится операционной системой и т.п. вне вашей предметной области.

Эту задачу за вас решили разработчики вашей операционки.
Это для них, а точнее для отдела пользовательских интерфейсов «UI» является предметной областью.

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


Допустим, я интегрирую ERP-систему и e-commerce систему. Это разные предметные области с разными моделями (данных в первую очередь, и предметной области во вторую). Я не создаю новую, обобщённую модель предметной области (или обобщённую модель данных) для результата композиции двух систем. Я в каждой системе работаю со своей моделью данных / моделью предметной области, производя реструктуризацию данных из одной модели в другую на стыке двух систем.


Граница между ERP-системой и e-commerce системой аналогична границе между UI и API при построении гридов, только масштаб другой. Данные мигрируют между различными областями, меняя свою структуру, но предметные области при этом не смешиваются. Реализация функционала для приложения "Банкинг" может потребовать выделения различных предметных областей в рамках одной информационной системы (UI, обработка, хранение). Да взять хотя бы версионирование процессов в BPMS, когда различные версии одного и того же бизнес-процесса оперируют с различным набором данных и имеют разное количество шагов. При этом различные предметные области (по версиям процесса) сосуществуют совместно в рамках одной информационной системы (правда между этими областями не происходит обмен данными, они параллельны в своём существовании).


В общем, спасибо за подкинутый материал. Было интересно помозговать на тему :)

Стоит добавить, что строить модель предметной области достаточно сложно и долго.
Человек, который в начале статьи задавал свой вопрос, не уточнил, что у него за задача. Поэтому полученный им ответ вполне может быть релевантным. Если CRUD приложение решит его задачу, то не за чем искать сложностей. Это будет анемичная модель в процедурном стиле, а такая архитектура будет архитектурой с анемичной моделью. Да и хрен бы с ней, пока она может эффективно решать задачу.
Это очевидные вещи, к сожалению в сумасшедшем мире их нужно объяснять, а некоторыве фреймворки типа джанги прямо гвоздями прибили модель к базе данных и целые толпы разрабочиков думают что модель это маппинг в базу, хотя само слово модель совсем о другом.
Пока академики рассказывают — джанги работают и приносят деньги. Не забывайте про это, хоть кому-то это покажется несправдливым.
При чём тут оправданность, в случае простого CRUD'а подход джанги отлично работает, а вот чуть сложнее начинаются костыли, их конечно делают, они работают и приносят деньги, да только не стоит забывать, что это не лучшее решение.
Имхо, у Джанга тоже неслучайно так устроена. Есть некоторая проблема в разбивании на слои данных и бизнес логики. ИМХО она в том, что в реале данные храняться в базе данных и часть отношений между данными формулируются в виде отношений и ограничений в базе данных. Поэтому если мы выделяем бизнес логику в отдельный слой, то бизнес логика как ты ни крути будет размазана бежду базой и этим слоем.
Я слышал что это чисто исторические причины, просто её изначально делали для для простого кейса.
А ограничения в базе очень далеки от бизнес-логики, это просто обеспечение целостности данных.
А насчет отношений между таблицами и полями, они тоже не имеют отношения к бизнес логике?
Что вы имеете ввиду под отношениями?
Это и есть целостность данных о которой я говорил.
Модель предметной области конечно включает в себя структуру сущностей и пользуется ими, но суть модели это поведение, сценарии.
Создание заказа, обработка входящего платежа, даже регистрация пользователя это сценарии который делают намного больше чем простое сохранение в одну таблицу.
Конечно, только это не отменяет того, что часть бизнес логики будет в моделях, которые маппятся на таблицы, а часть — в слое бизнес логики, где будут реализованы сценарии.
Я сейчас далек от этого, но я бы делал конечно слой бизнес логики. Просто ИМХО нужно помнить и понимать, что часть бизнес логики в моделях (в терминах Джанго), а часть в слое бизнес логики.
Даже если так, то это никак не меняет сути — модель это не мапинг объектов в базу, как это сделано в джанге, хотя модель конечно включает схему сущностей, но это лишь малая часть модели.
Ну, так это разные модели, только и всего. Я имею в виду термины.
Конечно модель данных это тоже модель, подмодель модели предметной области, но для реализации функционала системы нужно реализовать модель предметной области, а её в джанге пихать некуда, что вынуждает городить костыли.
Странная претензия. В таком фреймворке как Джанго, невозможно да и ненужно и даже вредно пытатся заранее предусмотреть все случаи. Никто не мешает там писать свой слой.
При чём тут все случаи, фреймворк должен задавать правильную арзитектуру.
Мне тут в аналогичной дискуссии предлагали такую штуку это похоже на правильное решение, но этим похоже никто не пользуется, поэтому скорее всего там туча граблей.
Sign up to leave a comment.

Articles