Тимур Шемсединов

До этого поделайте лабы на nodeschool.io и у меня на https://github.com/HowProgrammingWorks
Потом изучайте исходный код ноды для вникания в стиль: https://github.com/nodejs/node/tree/master/lib и уж потом проект.

Великий секрет архитектуры программирования заключается в том, что 0 для женского и 1 для мужского.

https://youtu.be/Try7lmWikao
habrahabr.ru/post/204958

Вот так всегда, очаровались красивой идеей, где-то что-то понравилось, руки чешутся применить... А нужно оно или не нужно... Отталкивайтесь от того, что хотите сделать, а Вы об этом так и не рассказали, и уже потом можно переходить к тому, какую парадигму выбрать, потом выбирать паттерны, фреймворки, библиотеки (но лучше как можно меньше их конечно). Вот для чего Вам CQRS? Что он будет решать и почему без него не лучше? Вы не сможете ответить на эти вопросы если не будете идти от задачи. А потом так и выходит: "что не напишу - все контроллер выходит, это наверно потому, что я все время думаю о контроллерах" )))

Вот три основных способа использования фабрик в JavaScript:

Фабрика объектов

// Объявление фабрики объектов
function Idiot(name) {
  return { name: name };
}
// создание экземпляра объекта
var idiot1 = Idiot('Bill');
console.dir(idiot1);

Фабрика классов

// Объявление фабрики классов
function PhilosophySchool(schoolName) {
  return function Philosopher(name) {
    return { name: name, school: schoolName };
  };
}

// Создание класса
var Stoicism = PhilosophySchool('Stoicism');
var philosopher = Stoicism('Marcus Aurelius');
console.dir(philosopher);

Фабрика прототипов

// Объявление базового прототипа
function Engineer(specialization) {
  this.specialization = 'Software';
};

Engineer.prototype.getName = function() {
  return this.specialization + ' engineer ' + this.name; 
}

// Объявление фабрики
function University(specialization) {
  function factoryConstructor(name) {
    this.name = name;
  };
  factoryConstructor.prototype = new Engineer(specialization);
  return factoryConstructor;
}

// Создание конструктора инженеров-программистов
SoftwareEngineer = University('Software');

// Создание экземпляра инженера-программиста
var alex = new SoftwareEngineer('Alex');
console.dir(alex.getName());

ООП это не архитектура, а парадигма. Скорее всего Вы хотели спросить, какие есть паттерны проектирования в парадигмах процедурного и структурного программирования. Перечислю кратко: модули (структурные блоки, библиотеки, часто построенные в иерархическую систему при помощи dependency injection), интерфейсы (наборы экспортируемых функций, которые видны снаружи модуля), шаблоны (функции, абстрагированные от типов данных, при помощи которых парадигма обобщенного программирования позволяет порождать типизированные реализации), слои (как ни странно, но до ООП тоже были абстракции, они реализовывались при помощи принципа разделения модулей на слои, т.е. группы модулей, реализующие более низкоуровневые или более высокоуровневые задачи, программирование обычно начинается с самого высокого слоя абстракций, из него можно использовать только вызовы на 1 слой ниже, но не на 2 слоя, т.е. нельзя смешивать абстракции и пропускать слои, обращаясь, грубо говоря, от нажатия кнопки сразу к кластеру на диске), заглушки (должны Вам должны быть известны, это функции и модули без реализации, необходимые чтобы запускать и отлаживать еще не дописанную программу, они могут выводить вызовы к ним на экран или в логи, а состоять только из возврата правдоподобных но не настоящих данных). Так же есть много паттернов структур данных, которые тоже очень сильно упрощают жизнь, если выбрать определенную их реализацию для своего проекта и придерживаться принципа однородности структур данных, например, не использовать две разные реализации двусвязных списков в одной программе (или модуле). Структуры данных вполне заменяют объекты, более того, работают они несравнимо быстрее, не создают проблемы неоднозначности моделирования, как в ООП например, когда Вы не можете решить, где должен находиться метод "сесть" у "жопы", у "стула" или у их общего контейнера "мир", в котором это происходит. Распространенные структуры данных: набор полей, список (в т.к. односвязный, двусвязный, циклический и т.д.), стек, дерево (тоже может быть от односвязного до пятисвязного с вариациями), множество, очередь, ассоциативный массив и хеш-таблица. Все, устал писать, рекомендую почитать Дэйкстру, Вирта, Кнута. А смириться с отсутствием ООП может помочь занятная статья в стиле холиварного срача: blogerator.ru/page/oop_why-objects-have-failed

Разумных вариантов миллиарды. А идиотских еще больше. Это как спросить, как лучше сделать автомобиль? Если бы был ответ на это вопрос, то была бы одна марка и одна модель.
Я бы советовал сделать описание вопросов на JSON, загружать эти данные со страницей или отдельным запросом, а потом рендерить на клиенте HTML из данных.

[
  { question: "Как Вас зовут?", type: "input" },
  { question: "Существует ли истина?", type: "select", answers: ["да", "нет"] },
  { question: "Как возможна справедливось?", type: "select", answers: ["легко", "трудно", "ни как"] }
]

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

ESB это обычно API в сервисной архитектуре, это RPC или REST, но принцип - атомарный вызов и получение ответов в виде кусков данных, это диалог в стиле клиент-сервер. А вот MQ - это совсем другое, это шины сообщений, тут вообще не происходит диалога в стиле запрос-ответ, а обмен данными происходит по принципу очередей сообщений, которые распределяются между каналами обработки (используется для масштабирования). По сути MQ - это реализация СМО (системы массового обслуживания), по которым можно найти много теории и которые уже давно широко используются в автоматизации технологических процессов на производстве, для транспорта и перевозок, в других сферах. RabbitMQ я не использовал, а про ZeroMQ могу сказать, что это гораздо больше, чем MQ. ZeroMQ - это не только шина событий, но и множество других паттернов обмена данными, как запрос-ответ, публикация-подписка и т.д. Посмотрите полный список этих паттернов: zguide.zeromq.org/page:all Из них можно собирать различные коммуникационные конфигурации. Шины сообщений и броккеры могут использоваться для построения ESB, но как одна из вспомогательных технологий.

Тут есть задача максимально отвязать оборудование от ПО. Конечно, ПО должно знать о структуре и возможностях оборудования, но эти знания можно обобщить и разработать специализированный язык-посредник, т.е. метаязык для формального описания протоколов (программных интерфейсов) устройств. При чем, синтаксические конструкции свои делать не нужно, лучше взять синтаксис, для которого уже разработаны распространенные и оптимизированные парсеры, например JSON. Таким образом, ПО будет знать не интерфейс оборудования, а языка описания этого интерфейса. Точнее, обобщенные элементы интерфейса, каждому из которых поставлены в соответствие обобщения более высокого порядка: команда (процедура, метод), параметр, датчик, измерение, и т.д. В этом метаязыке можно предосмотреть не только декларативные конструкции описательного характера, но и активные, включив в него скрипты например на JavaScript, которые могут описывать алгоритмы работы с теми же структурами, которые метаязык и описывает. Из декларативной части можно динамически строить и пользовательский интерфейс и связывать его с формированием конкретных команд, отправляемых в устройство. Более подробне описать не могу, т.к. не знаю специфики Ваших задач. О метапрограммировании можно кое-что почитать тут: habrahabr.ru/post/227753 и тут: habrahabr.ru/post/137446 ну может еще вот тут: habrahabr.ru/post/154891

Комплексное решение Rational Rose - www-03.ibm.com/software/products/ru/ratirosefami Для баз данных есть хорошие инструменты ErWin, BpWin - erwin.com Еще есть Visual Paradigm www.visual-paradigm.com но его я не пробовал. Думаю, что должны быть и другие альтернативы, можно гуглить по словам UML, RUP, software architecture modeling tools. Практически все они сводятся к UML диаграммам из которых потом можно скомпилировать скелет приложения, структуру каталогов и файлов, зачатки документации, заголовки библиотек, и т.д.

Может будет интересно посмотреть видео с моего доклада на JSLab в Одессе https://youtu.be/Try7lmWikao и слайды от доклада отдельно: www.slideshare.net/tshemsedinov/nodejs-architecture