Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады, список заявок под катом
Читать полностью »
Рубрика «domain-driven design» - 2
Началось голосование за доклады секции Backend на юбилейном DevConfX, который пройдет 21-22 июня в Москве
2019-06-07 в 13:22, admin, рубрики: domain-driven design, enterprise architect, php, php7.4, python, rad studio, symfony, tdd, Блог компании DevConf, высокая производительность, Разработка веб-сайтовПоваренная книга разработчика: DDD-рецепты (5-я часть, Процессы)
2019-06-04 в 13:48, admin, рубрики: clean architecture, domain-driven design, ruby, ruby on rails, Screaming Architecture, UML, uml-проектирование, use cases, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эвансВведение
В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.
Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.
Отделяем функциональные требования от бизнес требований.
Снова и снова случается так, что многие бизнес-идеи на самом деле не превращаются в конечный, намеченный продукт. Зачастую это происходит из-за неспособности понять разницу между бизнес-требованиями и функциональными требованиями, что в конечном итоге, приводит к несоответствующему сбору требований, ненужной документации, задержкам проекта и крупным проектным сбоям.
Или иногда мы сталкиваемся с ситуациями, в которых, хотя окончательное решение отвечает потребностям клиентов, но каким-то образом бизнес-цели не достигаются.
Поэтому крайне важно разделить бизнес-требования и функциональные требования, до того момента, как вы начнете их определять. Давайте разберем пример.
Поваренная книга разработчика: DDD-рецепты (4-я часть, Структуры)
2019-01-15 в 13:36, admin, рубрики: clean architecture, DDD, domain-driven design, Entity, patterns, ruby, ruby on rails, Screaming Architecture, Value Object, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эвансВведение
Итак, мы уже определились с областью применения, методологией и архитектурой. Перейдем от теории к практике, к написанию кода. Хотелось бы начать с шаблонов проектирования, которые описывают бизнес логику — Service и Interactor. Но прежде чем приступить к ним, изучим структурные паттерны — ValueObject и Entity. Разрабатывать мы будем на языке ruby. В дальнейших статьях разберем все паттерны, необходимые для разработки с использованием Вариативной архитектуры. Все наработки, являющиеся приложениями к данному циклу статей, соберем в отдельный фреймворк.
И мы уже подобрали подходящее название — LunaPark.
Текущие наработки выложенны на Github.
Разобрав все шаблоны, соберем один полноценный микросервис.
Как правильно работать с исключениями в DDD
2018-12-03 в 8:51, admin, рубрики: .net, C#, domain-driven design, exceptions, monads, onion architecture, Блог компании EastBanc Technologies, Проектирование и рефакторинг, Разработка веб-сайтов
В рамках недавно прошедшей конференции DotNext 2018 состоялся BoF по Domain Driven Design. На нем был затронут вопрос работы с исключениями, который вызвал жаркий спор, но не получил развернутой дискуссии, поскольку не являлся основной темой.
Также, изучая множество ресурсов, начиная от вопросов на stackoverflow и заканчивая платными курсами по архитектуре, можно наблюдать, что в IT-сообществе сложилось неоднозначное отношение к исключениям и к тому, как их использовать.
Наиболее часто упоминается, что с использованием исключений легко построить поток исполнения, имеющий семантику оператора goto, что плохо сказывается на читабельности кода.
Есть разные мнения о том, стоит ли создавать собственные типы исключений или использовать стандартные, поставляемые в .NET.
Кто-то делает валидацию на исключениях, а кто-то повсеместно использует монаду Result. Справедливо, что Result позволяет по сигнатуре метода понять, возможно ли не только успешное выполнение. Но не менее справедливо, что в императивных языках (к которым относится C#) повсеместное использование Result приводит к плохо читаемому коду, засыпанному конструкциями языка настолько, что с трудом можно разглядеть исходный сценарий.
В данной статье я расскажу о практиках, принятых в нашей команде (если кратко — мы используем все подходы и ни один из них не является догмой).
Речь пойдет об enterprise-приложении, построенном на базе ASP.NET MVC+WebAPI. Приложение построено по луковой архитектуре, общается с базой данных и брокером сообщений. Используется структурированное логирование в ELK-стек и настроен мониторинг при помощи Grafana.
Читать полностью »
Проектирование типами: Как сделать некорректные состояния невыразимыми на C#
2018-11-28 в 7:17, admin, рубрики: .net, C#, domain-driven design, архитектура, архитектура приложений, ооп, функциональное программированиеКак правило статьи, рассказывающие о проектировании типами, содержат примеры на функциональных языках — Haskell, F# и других. Может показаться, что эта концепция неприменима к объектно-ориентированным языкам, но это не так.
В этой статье я переведу примеры из статьи Скотта Власчина Проектирование типами: Как сделать некорректные состояния невыразимыми на идеоматичесий C#. Также я постараюсь показать, что этот подход применим не только в качестве эксперимента, но и в рабочем коде.
Поваренная книга разработчика: DDD-рецепты (3-я часть, Архитектура приложения)
2018-11-13 в 13:44, admin, рубрики: clean architecture, domain-driven design, ruby, ruby on rails, Screaming Architecture, Анализ и проектирование систем, архитектура приложений, Программирование, Проектирование и рефакторинг, проектирование сайтов, проектирование систем, Роберт Мартин, эрик эвансВведение
В рамках предыдущих статей мы выделили область применения подхода и рассмотрели основные методологические принципы Domain Driven Design.
В данной статье я хотел бы обозначить основные современные подходы к построению архитектуры корпоративных систем: Supple, Screaming, Clean и дать им свою четкую интерпретацию в виде полноценного готового решения.
В дальнейшем рассмотрим каждый шаблон проектирования подробно: обозначим область применения, приведем примеры кода, выделим рекомендуемые практики. В итоге, напишем готовый микросервис.
Проектирование типами: Как сделать некорректные состояния невыразимыми
2018-10-03 в 6:41, admin, рубрики: .net, domain-driven design, F#, архитектура, архитектура приложений, функциональное программированиеПредставляю вашему вниманию перевод статьи Scott Wlaschin "Designing with types: Making illegal states unrepresentable".
В этой статье мы рассмотрим ключевое преимущество F# — возможность "сделать некорректные состояния невыразимыми" при помощи системы типов (фраза заимствована у Yaron Minsky).
Рассмотрим тип Contact. В результате проведённого рефакторинга он сильно упростился:
type Contact =
{
Name: Name;
EmailContactInfo: EmailContactInfo;
PostalContactInfo: PostalContactInfo;
}Теперь предположим, что существует простое бизнес-правило: "Контакт должен содержать адрес электронной почты или почтовый адрес". Соответствует ли наш тип этому правилу?
Нет. Из правила следут, что контакт может содержать адрес электронной почты, но не иметь почтового адреса, или наоборот. Однако в текущем виде тип требует, чтобы были заполнены оба поля.
Кажется, ответ очевиден — сделать адреса необязательными, например, так:
type Contact =
{
Name: PersonalName;
EmailContactInfo: EmailContactInfo option;
PostalContactInfo: PostalContactInfo option;
}Но теперь наш тип допускает слишком многое. В этой реализации можно создать контакт вообще без адреса, хотя правило требует, чтобы хотя бы один адрес был указан.
Как же решить эту задачу?
Ответ на введение в проектирование сущностей, проблемы создания объектов
2017-02-16 в 6:50, admin, рубрики: DDD, design patterns, domain-driven design, php, ооп, Проектирование и рефакторингПосле прочтения статьи Введение в проектирование сущностей, проблемы создания объектов на хабре, я решил написать развернутый комментарий о примерах использования Domain-driven design (DDD), но, как водится, комментарий оказался слишком большим и я посчитал правильным написать полноценную статью, тем более что вопросу DDD, на хабре и не только, удаляется мало внимания.
Рекомендую прочитать статью о которой я буду здесь говорить.
Если вкратце, то автор предлагает использовать билдеры для контроля за консистентностью данных в сущности при использовании DDD подхода. Я же хочу предложить использование Data Transfer Object (DTO) для этих целей.
Введение в проектирование сущностей, проблемы создания объектов
2017-02-07 в 12:25, admin, рубрики: anemic domain model, code complete, design patterns, domain-driven design, mysql, php, rich domain model, ооп, Проектирование и рефакторингПри моделировании такого понятия предметно-ориентированного проектирования как сущность могут возникнуть некоторые сложности, обусловленные бизнес-требованиями или технической частью. В частности, иногда возникает сложность с созданием объекта-сущности.
В данной статье описываются две такие проблемы, и рассматривается способ их решения. Так же статья подойдет как введение в проектирование сущностей. Для понимания материала понадобится базовое представление о предметно-ориентированном проектировании.
Читать полностью »
Domain-Driven Design: стратегическое проектирование. Часть 1
2016-11-30 в 10:44, admin, рубрики: DDD, domain-driven design, Программирование, проектирование, Проектирование и рефакторинг, рефакторинг
Здравствуйте, хабрапользователи! В этой статье речь пойдет о предметно-ориентированном проектировании программного обеспечения с использованием, в первую очередь, стратегических шаблонов.
Данный подход использовал Вон Вернон в своей книге «Реализация методов предметно-ориентированного проектирования». Цель написания этой книги: дать возможность разработчикам совершить полет на самолете DDD (в детстве автор зачастую путешествовал со своей семьей на небольших самолетах). Вид с высоты дает более широкое представление о проблемах моделирования, не давая застрять в различных технических деталях. Наблюдая ландшафт DDD таким способом, можно осознать преимущества как стратегического, так и технического проектирования. Подробнее – под катом!Читать полностью »