Напиши ну возьми ты лезешь? Инжиниринг кода, ориентированный на бизнес

JavaScript
Напиши ну возьми ты лезешь? Инжиниринг кода, ориентированный на бизнес

После полугода планирования мы уже начинаем принимать гостей!

В этой статье много галантереи.Рекомендуется отрегулировать позу и посмотреть повторно.Все стеки технологий общие.В данной статье в качестве примера взят проект vue.

"Хороший код должен быть разработан! Вместо того, чтобы использовать отличный стек технологий"

DDD

Обратите внимание, что это не смеющийся смайлик, DDD (domain-driven design-domain-driven design), большинство фронтендов думают о том, как реализовать ту или иную функциональную деталь этого прототипа, когда получают спрос (какую UI-библиотеку использовать , как это написать)) ), даже не зная дела, вы можете развиваться и обычно добиваетесь своего. Такая ситуация называется-"Функциональное программирование (интерфейсные ресурсы без размышлений)".

Однако с углублением бизнеса и постоянной итерацией и изменением требований мы (внешняя часть), похоже, движемся вперед с большой нагрузкой.Почему?

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

Как разделены поля?

Вот примерно как этот реферат (только сильно нарисуйте), рекомендуется выполнять с задними одноклассниками"Подробное ♂♂ обсуждение"(лично я считаю, что абстрактным способностям нужно научиться думать + приобретенное обучение, а на статьи полагаться не могу)

Я думаю, что разработка программного обеспечения должна осуществляться на основе понимания продукта (или области отрасли), сначала абстрагируя модуль границ бизнеса в соответствии с проектом, создавая область, а затем развивая ее.

песочница

Упс, почему параметры в этом коде перепутались, а методы все зависят друг от друга, я не смею это изменить, почему в js 9000 строк

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

Это не кажется чем-то большим, давайте посмотрим на рекомендации, которые должны позволять вам шаблоны проектирования,

  • единственная ответственность
  • Принцип Деметры (наименьшее знание)
  • открытый закрытый принцип
  • Инверсия зависимости
  • Изоляция интерфейса
  • замена ребра

Как вы думаете, есть ли у DDD, принципов проектирования и среды песочницы одно и то же, что вы хотите подчеркнуть?

Кажется, я снова вернулся.Подолго болтая,поиграю со мной в словесные игры.Тебе нужно 300 000 или ты хочешь залезть на гору🧗?

Не так, если

""Я хочу удалить и добавить кусок кода (поле), не затрагивая исходный код, и не нужно ничего менять и не будет сообщения об ошибке, как это сделать?""

Далее я научу вас, как использовать его в разработке интерфейса.

структура

Общая структура каталогов проекта

Очень традиционная структура каталогов, включая vue-cli3, делает то же самое.В соответствии с функциями и обязанностями, если вы хотите изменить маршрут, перейдите в папку маршрутов, чтобы изменить его, и измените vuex, чтобы найти его в магазине.

Структура каталогов, разделенная DDD (не борюнники, пожалуйста, эвакуируйте быстро)

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

Опубликовать описание новой структуры каталогов

преимущество

Зачем это делать?

долг

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

  • Четко расставьте должностные обязанности и границы каждого коллеги
  • Проблема удобна для позиции до объема проблемы
  • Уменьшить конфликты кода

эффективность

  • Низкие затраты на техническое обслуживание
  • Многоразовая бизнес-зона
  • Масштабируемость (автоматизация, инфраструктура и т. д. в унифицированном режиме)

недостаток

  • Преобразование стиля кода и идей программирования
  • Совместимость старых проектов (конвертация по исторической задолженности)

Обязанности и детали в поле

Поскольку боязнь пространства слишком длинная (ленивая), в этой статье используется большое количество псевдокода (сознательная цветистость).

Объекты доступа к данным DAO (объект доступа к данным)

 static async getXxxList(api, payload) {
    const res = await api(payload);
    const { results, totalCount } = res.data.data;
    return { data: results, total: totalCount };
  }

Здесь нечего сказать Интерфейс и интерфейс API в поле обработки все размещены здесь Если вы хотите обрабатывать данные, то рекомендуется завершить это здесь, чтобы представление и данные были разделены, а не инкапсулировать данные в представлении.

Если обработка очень сложная, то рекомендуется наслоить DTO (Data Transfer Object) и поместить сюда логику.

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

Параметр/перечисление Модель

Обычно в нем две папки:

Перечислять его

некоторый избранный контент

[
  ["发布成功", 1],
  ["未发布", 2],
  ["等待中", 3],
  ["发布失败", 4]
  ....
]
Объект таблицы соответствий Vo

Поместите некоторые данные, соответствующие структуре таблицы, включая содержимое и параметры по умолчанию.

{
  // 团队 Number
  teamId = null;

  // 应用 String
  appName = null;

  // 申请人 Enums(Role)
  role = 1;

  // 开始时间 dateStr
  beginTime = null;

  // 结束时间 dateStr
  endTime = null;
}

маршрутизатор

Обратите внимание, что мы обычно пишем единую папку маршрутизатора на самом внешнем уровне, чтобы зарегистрировать сводку.

"Однако в домене вам нужна собственная маршрутизация и планируйте маршрут подразделения в соответствии с реализацией и бизнес-логикой домена."

Посмотреть Посмотреть

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

В определенном поле мидл-офисной системы для его поддержки может понадобиться 2-3 набора crud, тогда 2-3 набора соответствующих папок crud можно разместить под папкой View, а внутри папки находится структура представления (поиск форм, таблиц, сведений и т. д. разбивается по мере необходимости).

Vuex

Для нормального использования данные должны передаваться между различными единицами в домене, и не рекомендуется использовать их между доменами.

Регистрация реалма Main.js

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

Это что-то вроде модели публикации-подписки, что регистрируется? Сначала магический код

import routes from "./router";
export { routes };

// 领域模块名称
const MODULE_NAME = "Doctor";

// 注册模块能力
export default ({
  registerRouter,
  registerStore,
  registerApi,
  .......
}) => {
 // 使用模块能力
  registerRouter(MODULE_NAME, routes);
  registerStore(MODULE_NAME, store);
};

Увидел много параметров в начале реестра.Это кастомные возможности.Выньте регистрацию из центра компетенций.

"Анализ возможностей"

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

  • registerRouter регистрирует маршрут к модулю «Доктор»
 Doctor: {
    path: "/doctor/",
    name: "doctor",
    redirect: "/doctor/goodDoctor",
    component: () => import(/* webpackChunkName: "goodDoctor" */ "../view/Main"),
    children: [
      {
        path: "/doctor/goodDoctor",
        name: "goodDoctor",
        component: () =>
          import(/* webpackChunkName: "goodDoctor" */ "../view/goodDoctor/Index")
      },
      {
        path: "/doctor/badDoctor",
        name: "badDoctor",
        component: () =>
          import(/* webpackChunkName: "badDoctor" */ "../view/badDoctor/Index")
      },
    ]
  }
  • registerСохранить регистрацию врача на vuex в магазине
 Doctor: {
    goodDoctor:{
        namespaced: true,
        state,
        getters,
        mutations,
        actions
    },
    badDoctor:{
        namespaced: true,
        state,
        getters,
        mutations,
        actions
    }
 }

Есть еще много, чтобы не вдаваться в подробности

"расширять"

  • Закопанные точки для одного поля

  • Мониторинг производительности для одного домена

  • Мониторинг ошибок для одного домена

Есть еще много места для мечтаний (слепого мышления)...

Централизация — Обзор домена Module.js

В: После завершения стольких полей, как заставить его создать экземпляр и запустить проект?

Ответ: Смонтируйте сводку домена на vue.

// 获取src下的领域
import 领域1 from "@/领域1/main";
import 领域2 from "@/领域2/main";
——————————————————————————————————————
/*
也可以用
require.context('@', false, /\main.js/)
匹配所有src下领域内的main文件注册
*/

const modules = [领域1,领域2,领域3....];
new Center(modules).mount("#app");

Что именно делает этот центральный функциональный центр?

import Vue from "vue";
import App from "../App";

class Center {
  constructor(modules) {
  
    // modulesCenter做了层遍历,注册的所有内容放进函数以便获取
    modulesCenter(modules);

    Center.store = this.store = modulesCenter.createStore();
    Center.router = this.router = modulesCenter.createRouter();
    Center.vue = this.vue = new Vue({
      store: this.store,
      router: this.router,
      render: h => h(App)
    });
  }

  mount(mountEl) {
    this.vue.$mount(mountEl);
    return (Center.currentCenter = this);
  }
}

export default Center;

Что вы сделали, считается, что вы догадались.

  • createRouter
 const router = new VueRouter({
    mode: "history",
    ...modules.router
 });
  • createStore
 const store = new Vuex.Store({
    ...modules.store
 });

Общие поля данных

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

computed: {
    //都在 Doctor 内
    ...mapAction('Doctor',[
      '/goodDoctor',
      '/badDoctor',
    ])
}

Будущая композиция Api может быть легче.

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

Вы чувствуете, что смысл этого не пропорционален времени, которое это занимает? Давайте снова поднимем Nengli и посмотрим, как превратиться в бизнес со структурной обратной связью...  

Расширить инфраструктурный центр

  • Единая спецификация кода
  • Повторное использование кода домена (также в проектах)
  • Повышение производительности, в сочетании с webpack5+vite, вы можете кодировать только определенные поля
  • Унификация технической подготовки перед построением системы микроинтерфейса
вина домена
использовать поле

Прямое перетаскивание, низкий код или микросервис, не ограничивается выходной формой

Вспомогательные объекты

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

Резюме (время разговора)

  1. Думая о бизнесе
  2. Подключаемый
  3. Повысить эффективность

Не будь беспощадным сверхурочным"необходимая машина", требует соответствующей подготовки"Домен и интуиция кода", вместо этого может"Раскройте свою продуктивность", который можно отличить от"Интерфейсные ресурсы".


Советы: Зависимости и подключаемые функции здесь предназначены для получения данных текущего локального пользователя Хотите знать, как это сделать?

Тогда обратите внимание на самородки и публичные аккаунты в интерфейсе WeDoctor...

Интерфейс без опыта проектирования не является хорошим интерфейсом

Анализ производительности React — Fiber

На пути к эре двухмерной компоновки Grid

Не забудьте поставить лайк, подписаться, переслать и прокомментировать мое качество

Хотите попробовать этот стиль кода? Чтобы присоединиться к нам, пожалуйста, ищите единственный адрес электронной почты охранника:"yangyz1@wedoctor.com"