Базовый скрипт архитектора

Этот репозиторий содержит скрипты для создания простой схемы приложения бухгалтерского учета. Особое внимание уделяется анализу предметных областей на уровне сущностей.

Задача

Разработать приложение типа Trello/Asana, позволяющее командам управлять задачами проекта. Участники могут управлять списком задач и получать изменения по электронной почте или просматривать их в приложении. Приглашения в команды реализуются с использованием токенов. Роли участников: Администратор, Участник, Наблюдатель.

Скрипт

1. Определите предметные сущности

На этом этапе необходимо определить субъектные сущности. Тематические сущности имеют решающее значение для понимания предметной области.

Субъектная сущность — это объект, управляемый предметной областью.

В нашей задаче это: Пользователь или Актер (в контексте проекта), Команда, Задача, Проект, Роль.

Сущность субъекта

Существует два типа субъектно-независимых сущностей: референтные и артефактные.

  • Ссылочная сущность предмета содержит апостериорную (полученную на этапе формирования требований и позднее) справочную информацию (список позиций, сотрудник, подрядчик, склад). Коллекционирование может быть систематическим и консервативным или несистематическим и растущим. Жизненный цикл обычно длительный.

  • Объекты артефактов генерируются бизнес-процессами (заказ, счет-фактура, накладная, перемещение, бронирование). Коллекции не были систематизированы. Жизненный цикл довольно короткий.

» Существует еще один тип субъектной сущности — экземпляр, но он не является независимым.

» Сущность предметной ссылки не следует путать с классификатором. Классификатор содержит систематизированную априорную (известную до этапа формирования требований) справочную информацию, как правило, примитивную (ОКЕИ, КЛАДР, ОКВЭД, ОКАТО). Жизненного цикла не существует.

Подчиненные субъекты

Зависимая сущность — это зависимая (не независимая) сущность, которая существует только в контексте другой субъектной сущности.

  • Сущность процесса используется для хранения атрибутов (статус, баланс) основного состояния сущности, которые часто изменяются в бизнес-процессе).
    » Ссылочные сущности обычно извлекаются или дополняются из артефактных сущностей.
  • Подробные сущности используются для создания агрегированных наборов (коллекций, комбинаций) предметных сущностей (состав заказа/группы, статус склада). Основано на другом субъекте.
    » Агрегаты могут иметь либо изменчивое состояние (для ссылочных сущностей, таких как складские запасы), либо консервативное состояние (для артефактных сущностей, таких как состав заказа).

Беспринципная сущность

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

1.1 Исключите ложные сущности

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

Сохраняются следующие сущности: Пользователь, Задача, Проект, Роль.

1.2 Определите экземплярные сущности

Экземпляр (объект потока/значения) Сущность всегда существует как экземпляр в форме набора атрибутов. Экземплярная сущность всегда зависима, т.е является частью другой сущности (субъекта или детали). У них нет постоянных идентификаторов и собственных коллекций.

» Может существовать набор прототипов (шаблонов) таких сущностей, но не будет никакой связи между прототипами и сущностями экземпляров.

В нашем примере Задача — это экземпляр сущности, а Пользователь, Роль и Проект — это полные сущности.

1.3 Распознайте полиморфные сущности

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

В нашей задаче такого субъекта нет.

1.4 Распознайте мультиаспектные сущности

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

В нашей задаче такого субъекта нет.

2 Определите отношения между сущностями

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

В нашем примере мы имеем следующее соотношение:
• Проект – Участник (совокупные отношения)
• Проект – Задача (составная связь)
• Участники-роли (объединения)

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

• Пользователь — это субъектно-ориентированная, несистематическая сущность.
• Роль – предметная ссылка, систематизированная сущность.
• Проект – это субъектно-артефактная сущность.
• Taskᵉ — это сущность экземпляра.
• Задача — это детальная сущность, которая основана на сущности Задачаᵉ и подчиняется сущности Проект.
• Участник — это дочерняя сущность, основанная на сущности «Пользователь» и подчиненная сущности «Проект.

3 Определите события жизненного цикла сущностей

Определите события жизненного цикла сущности. Мероприятия помогут создать функциональную карту продукта.

4 Составьте список принципиальных функций продукта

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

5 Определите компоненты, необходимые для реализации каждой функции

На этом этапе необходимо определить некоторые основные моменты:
• Вам нужны внешние или внутренние компоненты?
• Нужно ли вам создавать новые компоненты или повторно использовать другие компоненты?
• Есть ли один или несколько компонентов, реализующих эту логику?
• Какие типы компонентов необходимы (приложения, веб-сайты, службы, базы данных, файлы и т д)?

6 Выберите технологии компонентов

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

7 Сгруппируйте компоненты в единицы развертывания

Отдавайте предпочтение шаблонам Monolith First, но не переусердствуйте.

В нашей задаче имеем:
• Приложение
• база данных
• Семейные услуги¹ Роль
• Проекты по обслуживанию домов (с функцией генерации токенов)
• Служба генерации уведомлений
• Служба отправки уведомлений
• Служба обмена сообщениями (SMTP-сервер)

¹ См определение ниже

» Отныне разделяйте здание осознанно и рационально, а не следуйте слепо модным тенденциям.

8 Эволюционируйте архитектуру

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

Большой продукт

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

Но сначала всем командам необходимо:
• Системное оборудование,
• Общий классификатор,
• Общая справочная информация по предмету.

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

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

  • Домен — это набор специализированных, несистемных сущностей и инструментов, используемых для реализации определенных видов деятельности предприятия.
  • Дом — это набор сущностей и инструментов, которые реализуют оставшуюся функциональность независимой субъектной сущности и ее контекста (за исключением Домена.

Обратите внимание, что каждая функциональная группа будет вести собственный профиль или сущность процесса для одного и того же субъекта. Давайте продемонстрируем это на примере сущности «Отдел продаж …
• Команда, осуществляющая ведение кадрового учета, будет вести кадровый учет организации.
• Команда, осуществляющая контроль запасов, будет поддерживать физический статус запасов.
• Команда, внедряющая финансовый учет, будет поддерживать финансовое благополучие предприятия.

Это одна из тех вещей, которая архитектурно нарушает принципы ООП, но позволяет эффективно создавать продукты.

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх