Nikolay Grigorev

TypeSrcipt. Part 2

2022-09-15T11:33:14.288Z

KeyOf

Оператор, который формирует литеральный тип из строк или чисел из типа

interface A { prop1: number; prop2: number; prop3: number; }

type B = keyof A; // B = 'prop1' | 'prop2' | 'prop3'

let b: B = 'prop1';

interface A { prop1: number; prop2: number; }

type B = { [K in keyof A]: any; };

const b: B = { prop1: 0, prop2: 1 };

Readonly, Readonly<T>

Оператор, который делает свойство типа только на чтение

Тип, который делает все свойства типа T только на чтение

interface A { readonly prop: number; }

type B = { readonly prop: number; };

type ReadonlyB = Readonly<B>;

class C { readonly prop = 0; }

const reaonlyD: ReadonlyArray<number> = [1, 2, 3];

const reaonlyE: readonly number[] = [10, 20, 30];

const reaonlyF: Readonly<number> = 10; // const reaonlyF = 10

const reaonlyF: Readonly<number> = 10; // const reaonlyF = 10

Partial<T>

Тип, который делает свойства типа T необязательными

interface A { AA: number; BB: number; CC: number; }

type B = Partial<A>; // interface B { AA?: number;… }

let b: B = { AA: 0 };

Omit<T, K>

Тип, который исключает из типа Т свойства

interface A { AA: number; BB: number; CC: number; }

type B = Omit<A, 'CC'>;

let b: B = { AA: 0, BB: 1 };

Pick<T, K>

Тип, который исключает из типа Т все свойства, кроме указанных

interface Todo { title: string; description: string; completed: boolean; }

type TodoPreview = Pick<Todo, 'title' | 'completed'>;

const todo: TodoPreview = { title: 'Clean room', completed: false };

Exclude<T, E>

Тип, который исключает значения из литеральных типов. Omit только для литеральных

type T0 = Exclude<'a' | 'b' | 'c', 'a'>; // T0: 'b' | 'c'

type T1 = Exclude<'a' | 'b' | 'c', 'a' | 'b'>; // T1: 'c'

type T2 = Exclude<string | number | (() => void), Function>; // T2: string | number

Extract<T, E>

Тип, который исключает все значения литерального типов, кроме переданных. Pick только для литеральных

type T0 = Extract<'a' | 'b' | 'c', 'a'>; // T0: 'a'

type T1 = Extract<'a' | 'b' | 'c', 'a' | 'b'>; // T1: 'a' | 'b'

type T2 = Extract<string | number | (() => void), Function>; // T2: () => void

NonNullable<T>

Тип, который не дает присваивать значения null и undefined

type T0 = NonNullable<string | number | undefined>; // T0 = string | number

type T1 = NonNullable<string[] | null | undefined>; // T1 = string[]

const t: T1 = null; // error. Type 'null' is not assignable to type 'string[]'

Parameters<T>

Тип, который формирует кортеж из входных параметров функции типа Т

type T0 = Parameters<() => string>; // type T0 = [];

const t0: T0 = []; const t0_2: T0 = [1, 2, 3]; // error. Type '[number, number, number]' is not assignable to type '[]'

type T1 = Parameters<(s: string) => void>; // T1 = [s: string]

const t1: T1 = ['str']; const t1_2: T1 = ['str1', 'str2']; // error. Type '[string, string]' is not assignable to type '[s: string]'

type T2 = Parameters<<T>(a: string, b: number) => boolean>; // T2 = [a: string, b: number]

const t2: T2 = ['atr', 2];

type T4 = Parameters<any>; // T4 = unknown[]

type T5 = Parameters<never>; // T5 = never

type T6 = Parameters<string>; // error

type T7 = Parameters<Function>; // error

Есть подобные тип:

ConstructorParameters<Type>
ReturnType<Type>
InstanceType<Type>
ThisParameterType<Type>
OmitThisParameter<Type>
ThisType<Type>

Record<U, T>

Тип, который формирует новый тип с полями из литерального типа U, где в свою очередь типы этих полей является типом T

interface ICat { age: number; breed: string; }

type CatName = 'BORIS' | 'MURKA' | 'KISS KISS';

const cats: Record<CatName, ICat> = { BORIS: { age: 10, breed: 'Persian' }, MURKA: { age: 5, breed: 'Maine Coon' }, ['KISS KISS']: { age: 16, breed: 'British Shorthair' } };

const objs: Record<'A' | 'B', { aa: boolean, bb: number }> = { A: { aa: true, bb: 1 }, B: { aa: false, bb: 2 } };

interface A { A: number; B: string; }

const objs: Record<keyof A, { aa: boolean, bb: number }> = {

A: { aa: true, bb: 1 },

B: { aa: false, bb: 2 }

};

Intrinsic String Manipulation Types

Встроенные типы манипуляций со строками

let upperText:Uppercase<string>;

upperText = "HELLO, WORLD"; upperText = "Hello, World"; // error. Type 'string' is not assignable to type 'Uppercase<string>'

let lowerText:Lowercase<string>; lowerText = "hello, world";

let capitalizeText:Capitalize<string>;

capitalizeText = "Hello, world";

let uncapitalizeText:Uncapitalize<string>;

uncapitalizeText = "hELLO, WORLD";

Лекция 2. Разработка систем на основе шаблонов

2020-09-15T09:18:06.250Z

Задачу, над которой вы сейчас работаете, кто-то уже наверняка решал!

Шаблон проектирования (Design Pattern)

Шаблоны проектирования представляют собой стандартные решения периодически повторяющихся проблем.

Шаблонам даны имена, чтобы облегчить специалистам их обсуждение;
Шаблоны представляют абстрактные базовые решения проблем, которые могут возникать в разных контекстах. Конкретная реализация в разных приложениях может быть различной.

История шаблонов. Строительство

1964. Работы Кристофера Александера в области строительства.

Причина: возросшая сложность требований и совершенствование материалов;
Общий принцип: отказ от случайных принципов проектирования;
Результат: 11 томов проектных решений (опубликованы 8). 243 взаимосвязанных проектных шаблона

Waist-High Shelf (полка на уровне пояса)
Thickening The Outer Wall (утолщение наружной стены)
Things From Your Life (вещи вашей жизни).

История шаблонов. Программное обеспечение

1991. Э. Гамма, Р.Хелм, Р. Джонсон, Д. Влиссидес. Конференция Object-Oriented programming, Languages & Applications:

Результатом встречи стала совместная разработка 23 шаблонов проектирования Gang of Four (GoF)

1993. Кент Бек, Вард Каннингам. Привлечение идей Александера к разработке систем на базе метафор:

Идеи положены в основу eXtreme Programming

2003. Мартин Фаулер. Patterns of Enterprise Application Architecture.

Зачем учить шаблоны?

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

Вопрос: Если паттерны так хороши, почему никто не оформил их в виде библиотеки?
Ответ: Паттерны относятся к более высокому уровню, чем библиотеки. Они
определяют способы структурирования классов и объектов для решения некоторых задач, а наша задача – адаптировать их для своих конкретных приложений.

Единая номенклатура

Номенклатуры паттернов обладают большой ВЫРАЗИТЕЛЬНОСТЬЮ. Используя паттерны в общении с другим разработчиком или группой, вы передаете не только название паттерна, но целый набор характеристик, качеств и ограничений, представленных данным паттерном.

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

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

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

Более увлекательная книга по паттернам для новичков

Состав шаблона (по GoF)

Имя. Сославшись на имя мы сразу можем описать проблему проектирования, её решение и следствия;
Задача. Описание того, когда следует применять шаблон, т.е. контекст;
Решение. Описание элементов дизайна, отношений между ними и функций каждого элемента;
Результаты. Следствия применения шаблона и разного рода компромиссы.

Классификация шаблонов проектирования

Распределения обязанностей
Порождающие
Структурные
Поведения

GRASP (General Responsibility Assignment Software Patterns — общие шаблоны распределения обязанностей) — паттерны, используемые в ООП для решения общих задач по назначению обязанностей классам и объектам.

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

GRASP-паттерны

Information Expert – Информационный эксперт (Эксперт)
Creator – Создатель
High Cohesion - Высокое зацепление
Low Coupling - Низкая связность
Pure Fabrication – Чистая синтетика
Indirection - Посредник
Do Not Talk to Strangers – Не разговаривай с незнакомцами.

Information Expert (Эксперт)

Задача. Каков наиболее общий принцип распределения обязанностей между объектами?
Решение. Назначить обязанность информационному эксперту – классу у которого имеется вся информация для выполнения обязанности.

Шаблон Information Expert определяет базовый принцип назначения обязанностей. Он утверждает, что обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом. Возможно, этот шаблон является самым очевидным из девяти, но вместе с тем и самым важным.

Если дизайн не удовлетворяет этому принципу, то при программировании получается спагетти-код, в котором очень трудно разбираться. Локализация обязанностей позволяет повысить уровень инкапсуляции и уменьшить уровень связанности. Кроме читабельности кода повышается уровень готовности компонента к повторному использованию.

Creator

Экземпляры B должны порождать экземпляры A, если:

Класс B содержит или агрегирует объекты A;
Класс B записывает экземпляры объектов A;
Класс B активно использует объекты A;
Класс B обладает данными инициализации для объектов A.

Шаблон Creator решает, кто должен создавать объект. Фактически, это применение шаблона Information Expert к проблеме создания объектов. Более конкретно, нужно назначить классу B обязанность создавать экземпляры класса A, если выполняется как можно больше из выше указанных условий.
Альтернативой создателю является шаблон проектирования Фабрика. В этом случае создание объектов концентрируется в отдельном классе.

Controller

Задача. Кто должен отвечать за обработку входных системных сообщений?
Решение. Делегировать обязанности по обработке системных сообщений классу, удовлетворяющему одному из следующих условий:

Класс представляет систему в целом;
Класс представляет собой сценарий прецедента:

<Прецедент>Controller – описывает шаги прецедента;
<Прецедент>Session – состояние выполнения сценария (Применим в stateless-системах, например, WEB).

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

Иногда класс-контроллер представляет всю систему в целом, корневой объект, устройство или важную подсистему (внешний контроллер).

Low Coupling (низкая связанность)

Задача. Как снизить влияние изменений и повысить степень повторного использования?
Решение. Распределять обязанности, что бы связанность оставалась низкой.

High Cohesion (высокое зацепление)

Задача. Как обеспечить возможность управления сложностью?
Решение. Распределять обязанности, поддерживая высокую степень зацепления.

Polymorphism

Полиморфизм позволяет обрабатывать альтернативные варианты поведения на основе типа и заменять подключаемые компоненты системы. Обязанности распределяются для различных вариантов поведения с помощью полиморфных операций для этого класса. Все альтернативные реализации приводятся к общему интерфейсу.

Пример: Strategy, State (GoF)

Pure Fabrication («Чистая выдумка» или «Чистая синтетика»)

Задача. Какой класс должен обеспечить реализацию Low Coupling и High
Cohesion, если Information Expert не обеспечивает подходящего решения?
Решение. Присвоить группу обязанностей с высокой степенью зацепления классу, не представляющему конкретного понятия предметной области

Пример: Production, Repository, (GoF)

Indirection (Непрямое связывание)

Проблема. Как распределить обязанности, при отсутствии прямого связывания между объектами?
Решение. Присвоить обязанности промежуточному объекту для обеспечения связи между объектами или службами

Пример : Adapter (GoF), MVC

Protected Variations (Защита от изменений)

Шаблон Protected Variations защищает элементы от изменения других элементов (объектов или подсистем) с помощью вынесения взаимодействия в фиксированный интерфейс. Всё взаимодействие между элементами должно происходить через него. Поведение может варьироваться лишь с помощью создания другой реализации интерфейса.

Разработчик: Хм, но разве дело не сводится к ОО-проектированию? Если я следую принципам инкапсуляции, знаю об абстракции, наследовании и полиморфизме. то зачем мне думать о паттернах проектирования? Для чего тогда были нужны те курсы ОО-проектирования? Я думаю, паттерны проектирования полезны только тем, кто не разбирается
в ОО-проектировании.

Гуру: О, это одно из известных заблуждений объектно-ориентированной разработки: будто знание основ ООП автоматически позволит вам строить гибкие, удобные в сопровождении и при годные к повторному использованию системы.

Разработчик: Нет?

Гуру: Нет. Более того, принципы построения ОО-систем, обладающих
такими свойствами, далеко не всегда очевидны.

Разработчик: Кажется, я начинаю понимать. И на основе этих неочевидных
принципов построения объектно-ориентированных систем
были сформулированы ...

Гуру: ... да, были сформулированы паттерны проектирования.

Лекция 1

2020-09-08T09:14:36.490Z

Информационная система

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

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

Классификация ИС

По архитектуре

По степени автоматизации
По характеру обработки данных
По сфере применения
По масштабу

Архитектура ИС

Откуда "берется" архитектура

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

Архитектурные слои, уровни, подсистемы и компоненты

Подсистема (Subsystem). Набор взаимодействующих компонентов, работающих совместно для достижения определённой цели;
Компонент (Component). Структурная составляющая подсистемы;
Слой (Layer). Группирует логически связанные подсистемы и определяет правила для связи между слоями;
Уровень (Tire). Аппаратный компонент распределённой системы на котором может функционировать слой.

Принципы проектирование слоев

В каждом слое ничего неизвестно о слоях более высокого уровня;
В каждом слое ничего неизвестно о строении других слоёв. Связь осуществляется только через интерфейсы подсистем;
Некоторые компоненты подсистем являются внутренними для подсистемы, другие имеют интерфейсы для подсистем верхнего слоя;
Предположения относительно существования других слоёв являются минимальными
Связь между подсистемами ограничена явными аргументами. Глобальные данные недопустимы.

Преимущества слоев (М. Фаулер)

Каждый слой можно воспринимать как единое целое, не заботясь о наличии других слоёв;
Можно выбирать альтернативную реализацию базовых слоёв;
Зависимости между слоями можно свести к минимуму;
Каждый слой является удачным кандидатом на стандартизацию;
Созданный слой может служить основой для нескольких различных слоёв более высокого уровня.

Недостатки слоев

Изменения в одном из слоёв базового уровня часто приводят к каскадным изменениям в слоях более высокого уровня (пример: новый атрибут в таблице БД);
Наличие избыточных слоёв может снизить производительность системы.

Три основных слоя

Представление (Presentation)
Предоставление услуг, отображение данных, обработка событий пользовательского интерфейса;
Домен (Domain)
Бизнес-логика приложения
Источники данных (Data Source)/ Слой доступа к данным (Data Access Layer или DAL)
Обращение к базе данных, обмен сообщениями, управление транзакциями и т. д.

Распределение слоёв по уровням

Традиционные архитектуры

Централизованная архитектура

70-e годы. Эпоха мейнфреймов - больших централизованных ЭВМ.

Основные особенности:

Все базовые функции приложения реализуются в одной месте
Все пользователи работают одновременно на одном компьютере

Плюсы:

«Нулевое» администрирование рабочих мест пользователей;
Централизованная разработка и обслуживание системы.

Минусы:

Дорогая аппаратура оправдана только для больших систем;
Взаимная зависимость пользователей на программном уровне.

Персональные компьютеры

Начало 80-х — персональные компьютеры.

Основные особенности:

Все базовые функции приложения реализуются в одной месте;
Однопользовательский режим работы приложений.

Плюсы:

Полная автономность работы. Мобильность приложений;
Развитый пользовательский интерфейс - как следствие монополизации
аппаратного обеспечения.

Минусы:

Серьезные ограничения в вычислительной мощности;
Крайне затруднен обмен данными. Дублирование информации;
Начало 80-х — персональные компьютеры.

Распределенные системы

Распределенные системы должны также относительно легко поддаваться расширению, или масштабированию. Эта характеристика является прямым следствием наличия независимых компьютеров, но в то же время не указывает, каким образом эти компьютеры на самом деле объединяются в единую систему.

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

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

Альтернативы распределения слоёв

Модели архитектуры «клиент-сервер»

Модели отражают распределение слоёв между компьютерами сети

Функции ввода и отображения данных (слой представления);
Прикладные функции, характерные для предметной области приложения (слой домена);
Функции накопления информации и управления данными (слой доступа к данным, слоев данных).

Модель RDA (модель «файл-сервер»)

Появились локальные сети. Файлы начали передаваться по сети. Сначала были одноранговые сети - все компьютеры равноправны. Возникла идея хранения всех общедоступных файлов на выделенном компьютере в сети - файл-сервере.

Файл-серверные приложения — приложения, схожие по своей структуре с локальными
приложениями и использующие сетевой ресурс для хранения данных.
Функции сервера: хранения данных и управление файлами.
Функции клиента: обработка данных происходит исключительно на стороне клиента.

Плюсы:

Многопользовательский режим работы с данными;
Удобство централизованного управления доступом;
Низкая стоимость разработки.

Минусы:

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

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

Файл-сервер — распределение слоев

Модель DBS (двухзвенная модель)

Начало 90-х – архитектура «клиент-сервер».

Под «клиентом» обычно подразумевают компьютер конечного пользователя или программный код, выполняющий запрос к серверу (потребляющий услугу). «Сервером» обычно называют машину или программный код, предоставляющий сервис / отвечающий на запросы.

Ключевым отличием архитектуры клиент-сервер от архитектуры файл-сервер является
абстрагирование от внутреннего представления данных (физической схемы данных).
Теперь клиентские программы манипулируют данными на уровне логической схемы.

Основные особенности:

Клиентская программа работает с данными через запросы к серверному ПО;
Базовые функции приложения разделены между клиентом и сервером.

Плюсы:

Полная поддержка многопользовательской работы;
Гарантия целостности данных .

Минусы:

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

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

Модель DBS (двухзвенная модель)

Комплексный сервер (двухзвенная модель)

Модель AS (трехзвенная модель)

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

Трехзвенная архитектура

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

Преимущества сетевой архитектуры «Клиент-сервер»

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

Недостатки архитектуры «клиент-сервер» с точки зрения информационной безопасности

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

Архитектура «клиент-сервер» на базе технологии Web

Введение в АрхИС

2020-09-02T20:54:28.655Z

Цель

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

Задача курса

Иметь представление о роли информационных систем в производстве (организации) во взаимосвязи с архитектурой предприятия
Знать и применять на практике

методы анализа требований для формирования высокоуровневой архитектуры ИС;
архитектуры информационных систем;
методы проектирования информационных систем в целом и их компонентов;
современные средства реализации информационных систем.

Базовые знания/навыки для курса

Основные понятия: система, ИС, ИТ, АИС, классификация ИС и др.;
Исследование и структурное моделирование предметной области. Понятие бизнес-процесса. Формулирование требований к системам;
ООП. Построение объектно-ориентированных моделей предметной области;
Построение UI и/или разработка приложений, ориентированных на Веб;

Источники информации и знаний

Теория

Иан Соммервилл, Инженерия ПО;
Д. Р. Трутнев, Архитектура ИС. Основы проектирования;
Б. Ю. Гриценко, Архитектура предприятия.

Практика

Мартин Фаулер, Шаблоны корпоративный приложений;
Руководство Microsoft по проектированию архитектуры приложений;
Эрик Эванс, Предметно-ориентирование проектирование (DDD);
Л. А. Мацяшнек, Б. Л. Лионг, Практическая программная инженерия.

Статьи

Инструменты и технологии

IDE: Visual Studio 2019;
Text editor: Visual Studio Code/Subline/Atom или другой;
Terminal: WindowsTerminal/CommandLine/PowerShell или другой;
VCS (Version Control System): GIT;
.NET (.NET Core last version, .NET Framework last version);
CASE (набор инструментов и методов программной инженерии для проектирования ПО): Visual Paradigm, Draw.io, MS Visio.