Почему к DDD обычно подходят не с той стороны? А с какой стороны надо? Какое отношение ко всему этому имеют жирафы и утконосы?
Специально для Хабра — текстовая расшифровка доклада «Domain-driven design: рецепт для прагматика». Доклад был сделан на .NET-конференции DotNext, но может пригодиться не только дотнетчикам, а всем интересующимся DDD (мы верим, вы осилите пару примеров кода на C#). Видеозапись доклада также прилагается.
Читать полностью »
There are only two hard things in Computer Science: cache invalidation
and naming things.— Phil Karlton
We, developers, spend more time reading code than writing it. It is important for the code to be readable and clear about its intent.
Below are some advice based on my experience naming things.
Итак, мы уже определились с областью применения, методологией и архитектурой. Перейдем от теории к практике, к написанию кода. Хотелось бы начать с шаблонов проектирования, которые описывают бизнес логику — Service и Interactor. Но прежде чем приступить к ним, изучим структурные паттерны — ValueObject и Entity. Разрабатывать мы будем на языке ruby. В дальнейших статьях разберем все паттерны, необходимые для разработки с использованием Вариативной архитектуры. Все наработки, являющиеся приложениями к данному циклу статей, соберем в отдельный фреймворк.
И мы уже подобрали подходящее название — LunaPark.
Текущие наработки выложенны на Github.
Разобрав все шаблоны, соберем один полноценный микросервис.
Довелось мне как-то после нескольких проектов на React поработать над приложением под Angular 2. Прямо скажем, не впечатлило. Но один момент запомнился — управление логикой и состоянием приложения с помощью Dependency Injection. И я задался вопросом, удобно ли управлять состоянием в React используя DDD, многослойную архитектуру, и внедрение зависимостей?
Если интересно, как это сделать, а главное, зачем — добро пожаловать под кат!
Привет!
Мы приступаем к переводу книги Криса Ричардсона "Microservices Patterns. With examples in Java". До премьеры на русском языке еще с полгода, но мы хотели бы предложить вам своеобразный трейлер — немного сокращенный обзор этой книги от Бена Нейдела (Ben Nadel), прочитавшего MEAP-версию. В обзоре активно цитируется текст Kindle-версии Ричардсона.
Добро пожаловать под кат!
Читать полностью »
Эта статья — часть «Хроники архитектуры программного обеспечения», серии статей об архитектуре ПО. В них я пишу о том, что узнал об архитектуре программного обеспечения, что я думаю об этом и как использую знания. Содержание этой статьи может иметь больше смысла, если вы прочитаете предыдущие статьи в серии.
После окончания университета я начал работать учителем средней школы, но несколько лет назад уволился и пошёл в разработчики программного обеспечения на полный рабочий день.
С тех пор я всегда чувствовал, что мне нужно восстановить «потерянное» время и узнать как можно больше, как можно быстрее. Поэтому я стал немного увлекаться экспериментами, много читать и писать, уделяя особое внимание дизайну и архитектуре программного обеспечения. Вот почему я пишу эти статьи, чтобы помочь себе в обучении.
Читать полностью »
И снова здравствуйте!
Что ж очередной «новый» курс, который стартовал в конце декабря, подходит к концу — «Backend разработчик на PHP». Учли разные мелкие шероховатости и запускаем новый. Осталось только посмотреть на выпуск и всё, поставим очередную галочку.
А счас пока давайте посмотрим на одну интересную статью.
Поехали.
В этой статье вы узнаете, как использовать PHP для управления следующим DDD-проектом вашей компании и эффективно моделировать реальные ситуации, чтобы помочь определить вашу бизнес-логику.
Предметно-ориентированное проектирование (Domain-Driven Design, в дальнейшем — DDD) — это методология разработки программного обеспечения для проектирования сложных программных проектов с целью доставки конечного продукта, который отвечает задачам организации. Фактически, DDD способствует фокусированию проекта на развивающейся базовой модели.
DDD научит вас эффективно моделировать реальный мир в вашем приложении и использовать ООП для инкапсуляции бизнес-логики организации.
Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомиться в оригинале). Перевод второй — по ссылке. И так как он вызвал БЕШЕННЫЙ ажиотаж(целых ДВА человека подискутировали со мной в комментах), то не перевести третью было бы преступлением.
В предыдущей статье мы обсудили разумную систему расслоения проекта, состоящую из трех слоёв:
Сейчас, подробно рассмотрим инфраструктурный слой.
В 2017 году Matthias Noback (автор A year with Symfony) опубликовал цикл из трех статей, в котором описал свои взгляды на идеальную архитектру корпоративных приложений, сформировавшуюся за долгие годы практики.Первая часть является вводной и не представляет особого интереса(можно ознакомитсья в оригинале). Переводом второй является данная статья. Перевод третьей будет доступен в скором времени.
Для меня, одним из обязательных требований, к "чистой" архитектуре, является грамотное разделение кода приложения по слоям. Сам слой не делает ничего, вся соль в том, как он используется и какие ограничения накладываются на компоненты, ему принадлежащие. Давайте немного пофилософствуем, перед тем как рассмотреть конеретные практические приемы.
YiiConf — конференция по PHP-фреймворку Yii, уже близко. Если ещё не оформили билет — самое время. И не забудьте указать свой никнейм при регистрации — это очень поможет найти знакомых, с которыми вы общались виртуально.
Сегодня выложили программу докладов и мастер-классов, собранную из поданных заявок как на основе голосования участников конференции и сообщества Yii, так и на основе опыта организаторов.
