Автор Kid Ant Financial Data Experience Technology Team
По мере того, как решаемые нами сценарии становятся все более специализированными и сложными, а масштабные приложения SPA становятся все более популярными, клиентская часть берет на себя все больше и больше обязанностей. Качество кода и целостность системы становится все труднее понять. Легко повторять и повторять, чтобы обнаружить, что код нельзя изменить. В конце концов, мы можем только начать заново и заново развиваться. в конечном счете复杂度的失控, в этой статье мы попытаемся проанализировать проблемы и前端如何应用领域模型Некоторые предложения даны с точки зрения развития.
Почему итерация становится все труднее
Архитектура нашей системы тщательно разработана для управления сложностью в соответствии со стандартными уровнями системы.逻辑层,展示层,数据层. Каждый слой тщательно продуман. Мы абстрагируем отдельные классы, чтобы поместить общую логику. Продолжайте рефакторить код и абстрагируйте точки, которые можно использовать повторно. Почему изменения в требованиях часто могут разрушить наши разработки.
причина в следующем:
- Сама проблемная область сложна
- Техническая модель не соответствует модели предметной области
- потеря знаний
Сама проблемная область сложна
Программное обеспечение само по себе предназначено для управления сложностью, и проблемные области, с которыми мы сталкиваемся сейчас, сложны. Чтобы создать действительно полезное программное обеспечение, разработчики должны иметь соответствующие знания. Широта знаний, необходимых для этого, пугает. Если мы не можем понять проблемную область, мы не можем контролировать сложность проблемной области.
Когда сложность выходит из-под контроля, разработчики не могут понять программное обеспечение. Лучшая идея лежащей в основе технологии не помогает, когда сложность предметной области не решается.
Техническая модель не соответствует модели предметной области
Дизайны, которые я описал выше,技术层面дизайн. Нам легко абстрагировать отдельный класс, чтобы поставить общую логику, но трудно дать ему业务上的定义• Этот общий класс является общим только в техническом измерении.
Проблема в обобщении в техническом измерении很容易被业务摧毁. Изменения в спросе или расширение, обобщение технических размеров может быть легко разрушено. Например, если страница изменяется и повторно используется определенный компонент представления, он может быть извлечен в общий каталог верхнего уровня. То есть техническую модель сразу нужно переделывать, а потом рефакторить до чистого вида, который нравится инженерам. Потом требования меняются, а потом рефакторинг.... попадает в замкнутый круг.
И на данном этапе нам сложно обеспечить эффективный ход рефакторинга.Есть теория под названием破窗户теория. Старое здание, как только разбивается первое окно, сразу же дает признаки ветхости и коррупции. Как в машине, когда разбивается первое окно, внутри быстро разрушается.
Основная причина в том, что мы разработали技术模型и领域模型Несоответствие. Поэтому для каждого изменения требований изменения, отображаемые в технической модели, могут быть огромной рабочей нагрузкой. Мы даже не можем его изменить вообще, когда бизнес-давление очень велико, мы можем только сказать продакт-менеджеру, что это можно сделать, но нам нужно 2 месяца. Результатом, скорее всего, станет компромисс со стороны спроса, приносящий в жертву интересы пользователей. Это делает продукт все более и более сложным в использовании.
потеря знаний
Знания теряются в любом проекте, и аутсорсинговые системы могут возвращать только код, а не знания. Уходят в отставку, передаются, знания теряются один раз, почему-то устно их не передают.
Утерянные знания также сделают систему все более и более сложной в обслуживании.Новые студенты не знают, что произойдет с изменениями в общей логике.Кодекс в конечном итоге становится «нефтяной ямой», становится все глубже и глубже и в конечном итоге не может выбраться самих себя.
Суммировать
Корень вышеупомянутых трех проблем в том, что мы не описали четко наш бизнес во внешнем коде. Мы часто视图驱动, вместо业务驱动. Большую часть времени нас волнует только то, как выглядит страница и какие данные берутся с запросом. Поэтому в плане бизнес-концепций у всех разная глубина понимания. Для решения этой проблемы может оказаться более целесообразным принять новый метод разработки, основанный на предметной области.
Дизайн, управляемый доменом
Модель предметной области — это единый язык для разработки внешнего интерфейса, внутреннего интерфейса и конечного продукта. Единый язык может не только формировать единое понимание, но и способствовать постоянному совершенствованию модели предметной области. Это также заставляет разработчиков изучать важные бизнес-принципы, а не разрабатывать механические функции. Менеджеры по продукту также будут продолжать совершенствовать свои знания и улучшать собственное понимание. Без единой структурированной модели, основанной на консенсусе, проект быстро станет негибким и в конечном итоге станет устаревшей системой, обслуживание которой обходится дорого.
Модель предметной области внешнего приложения
Во многих случаях модели предметной области создаются студентами, работающими на бэкенде. Я подытожил эволюцию нашей системы, надеясь вдохновить вас:
- Понимание модели серверного домена
- Создайте интерфейсную модель домена
- отдельный слой домена
- доминирующее соглашение об интерфейсе
- Обратите внимание на последствия для бизнеса в разработке
- синхронизация в реальном времени
Понимание модели серверного домена
Прежде чем приступить к внешнему дизайну, нам нужно понять бизнес-значение, которое мы хотим развивать. Помимо самостоятельного понимания и построения модели, мы можем обратиться за помощью к одноклассникам.拿到他们的领域模型, чтобы выяснить их модульное деление. На самом деле они являются окончательными реализаторами бизнес-логики, и мы можем напрямую учиться на их моделях, что также может гарантировать, что внешний и внутренний интерфейсы имеют последовательное понимание бизнес-модели.
Создайте интерфейсную модель домена
Мы хотим нарисовать диаграмму модели внешнего домена, которая в значительной степени согласуется с диаграммой модели внутренней области, но绝不是一样из. Обычно проще, чем бэкэнд-модель. Например, на странице нужно настроить задачу, эта конфигурация может быть достаточно сложной в бэкэнд-модели (она будет использоваться для выполнения некоторых сложных операций, таких как тот же коэффициент цепочки), но в нашей фронтенд-модели его бизнес-функция — это простая конфигурация задачи~
отдельный слой домена
Как показано на рисунке, эта точка должна приходиться на код核心! ! Обязательно выделите в коде отдельный слой домена в соответствии с соответствующей моделью домена внешнего интерфейса. Модель должна быть тесно интегрирована с реализацией, должна направлять дизайн и落到代码上成为最终产品的一部分.
Также необходимо подчеркнуть, что построение доменного слоя не должно быть запросом с двух страниц одновременно, поэтому запрос извлекается и дается доменное имя. он, должно быть, был提前建立好из. Слой, который создается перед началом дизайна внешнего интерфейса.
Нам нужно извлечь все компоненты страницы и бизнес-поведение в модули и поместить их в соответствующие модули домена. Пока это деловое поведение,一定有一个领域模块可以落. Если нет, то дизайн модели предметной области нецелесообразен.
Следует понимать, что целью разделения доменного слоя является не повторное использование страницы, которая находится в思想上Должен быть конвертирован. Уровень предметной области не абстрагируется, поскольку он повторно используется в нескольких местах. Причина, по которой его вытащили:
- Слой домена
稳定(страница и модули, привязанные к странице, нестабильны) - Слой домена
解耦(страница будет связана, и данные страницы будут поступать из нескольких интерфейсов и нескольких полей) - Уровень домена имеет
极高复杂度, им стоит управлять отдельно (уровень представления занимается рендерингом страницы и управлением логикой страницы, сложность достаточно высока, а отделение уровня предметной области может облегчить слой представления.view层尽可能轻量Это основная идея нашего архитектора cnfi) - Слой домена
以层为单位возможно复用(ваш код может отказаться от определенной технической системы, переключиться с vue на react или может запустить мобильную версию, в этих случаях доменный слой может быть напрямую переиспользован) - Для устойчивости модели предметной области
衍进(Цель существования модели — заставить людей сосредоточиться. Преимущество сосредоточения — усилить понимание бизнеса фронтенд-командой, а процесс размышлений о бизнесе может заставить бизнес двигаться вперед)
Здесь я хотел бы процитировать слова нашего лидера, наша конкурентоспособность заключается не только в интерфейсе, наша конкурентоспособность заключается в том, что мы являемся интерфейсом отдела данных и в нашем понимании бизнеса данных. Только глубокое понимание бизнеса может вывести систему на правильный путь.
Доминируйте на этапе согласования интерфейса
Соглашение об интерфейсе, насколько это возможно,前端主导, ведь интерфейс используется фронтендом, и разумнее интерфейс проектировать фронтендом. А в процессе согласования у front-end студентов есть еще одна возможность ознакомиться с тем, как back-end делится на модули. Необходимо согласовать путь к интерфейсу и имена переменных, просмотрев базу данных бэкэнд-студентов и общий проектный документ, и это также может заставить бэкэнд-студентов назвать каждую часть системы. такой же.
Обратите внимание на последствия для бизнеса в разработке
Когда мы даем имена классам, методам и модулям, мы должны указывать их прямо.业务核心, чтобы соответствовать модели предметной области. Например, запись данных о сотруднике может быть преобразована в inputRec или employeeData, inputRec на самом деле является термином для компьютерного мышления, а employeeData является прямой ссылкой на проблемную область. Эту ошибку на самом деле очень легко сделать, мы разработали程序员思维根深蒂固.
синхронизация в реальном времени
Убедитесь, что все учащиеся в команде знакомы с моделью системы. Специально для новых студентов, которые хотят ознакомиться с кодом и изменить его, сначала поделитесь с ними моделью предметной области нашей системы, а затем познакомьтесь с технической архитектурой. Различия в направленности работы могут привести к различиям в мировоззрении программирования. Это приучит новых студентов оценивать, соответствуют ли они существующим моделям, прежде чем принимать технические решения. Постоянное размышление о модели может помочь нашему бизнесу расти.
Суммировать
Дизайн, управляемый предметной областью, оказывает очевидное влияние на снижение сложности проекта и разделение бизнес-логики внешнего интерфейса и логики представления. Слой бизнес-логики можно использовать повторно. Это углубляет понимание и размышления студентов о бизнесе, что может способствовать развитию бизнеса. Эта идея наслоения не ограничивается определенной структурой, я предлагаю вам попробовать ее ~
Если вам интересна наша команда, вы можете подписаться на рубрику и подписатьсяgithubИли отправьте свое резюме на tao.qit####alibaba-inc.com'.replace('####', '@'), приглашаем присоединиться людей с высокими идеалами~
Оригинальный адрес:GitHub.com/proto team/no…