• Представление модели предметной области (МПО) и точек интеграции

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

      В этой статье я расскажу о способе создания представления (диаграммы) модели предметной области (МПО), дополненное связями с точками интеграции, на базе которых построена функциональность системы: хранимыми процедурами, функциями и веб-сервисами. Таким образом, данное представление хорошо подойдёт проектам с большим количество точек интеграций и поможет разработчикам и аналитикам быстрее ориентироваться в проекте, порой даже не заходя в код.
      Читать дальше →
    • Методика проектирования архитектурных слоев на основе анемичной модели и DDD

      • Tutorial
      В результате выполнения методики будут выделены архитектурные слои с максимальной специализацией по уровням прикладных задач и разделением ответственности по SRP.

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

      Как следствие, это выражается:

      • в непредсказуемости сроков разработки
      • большим временем локализации ошибок
      • увеличением требования к квалификации разработчиков и сложной заменяемости

      Но как выйти на другой уровень качества приложения и разработки?

      Если сравнивать архитектуру систем с архитектурой зданий, то на определённом этапе, переполненную хрущёвку надо превратить в небоскрёб. Методика описывает то, КАК это сделать.

      image
      Читать дальше →
    • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление

        Сейчас сложно найти короткое и понятное определение таких понятий как «слой приложения» и «уровень абстракции». Это влечёт различия в понимании одного и того же либо непонимания данного понятия среди разработчиков. А недопонимания ведут к разногласиям.

        Цель этой статьи: совместно выработать определённость, создать у всех единое представление и выработать короткое, ясное и практичное определение для понятия Архитектурный слой в области корпоративных приложений. Всё что приводится в статье вы можете обсудить и дополнить в комментариях, а я актуализирую материал в статье в соответствии с замечаниями.

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

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


        В чём сейчас заключается путаница при работе с многослойной архитектурой:
        • принято считать, что слоёв должно быть 3: данные, бизнес-логика, интерфейса — но на самом деле слоёв может быть любое необходимое количество
        • нет критериев, по которым те или иные задачи относятся к тому или иному слою, что часто приводит, к созданию одного большого прикладного слоя, либо один какой либо из слоёв дорабатывается под задачи, не характерные для него
        • нет конкретного короткого определения
        • есть пересечения между понятиями слоя (layer), уровня и яруса (tier), к которым так же нет точных определений. По Фаулеру уровни относятся, подразумевая физическое разделение, а на практике такой определённости нет
        Читать дальше →
      • Реализация паттерна MVP на основе ApplicationController и IoC в WinForms приложении

          Добрый день!

          В этой статье я расскажу о том как я внедрял паттерн MVP в своём Windows Forms приложении и опишу практические ситуации и особенности использования IoC и ApplicationController. Переход от codebehind к MVP мне позволил:

          • улучшить читатемость за счёт лучшего разделения кода (SRP) — отделить BL от View;
          • выработать методику дальнейшего расширения функциональности приложения;
          • избавиться от singleton, который я использовал для работы с настройками приложения.
          Читать дальше →
        • 11 факторов и лайфхаков, которые повысят вашу эффективность

            В этой статье я рассмотрю устоявшиеся практики, которые помогают экономить такие ресурсы как время и энергию разработчика.

            На исследование этого вопроса давно меня вдохновляла книга «Как Герман Греф учил слона танцевать», в которой описываются различные процессы оптимизации производства, такие как lean-менеджмент и кайдзен. В то время вобрав в себя большое количество функций и процессов, я столкнулся со своей 100%-й загруженностью, при которой ощутимо прослеживалось влияние различных факторов на мою производительность и приходилось выбирать и эксперементировать, чтобы выиграть время. Это было особенно интересно с точки зрения управления ресурсами, так как большая часть «произодства» находилось внутри одной головы.
            Читать дальше →
          • История одного удачного применения SRP в Legacy проекте

            В этой статье я расскажу на примере эволюции своего проекта историю перехода и видение контрактного программирования.

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

            Что-то я буду описывать своим языком.
            Читать дальше →