Эта статья является переводом материала «Tackling Complexity in the Heart of DDD».
Давайте проведем небольшой эксперимент: попробуем объяснить суть предметно-ориентированного проектирования (DDD) тому, кто понятия об этом не имеет. Это, особенно если делать кратко, непросто. Ограниченные контексты, сущности, события домена, объекты значений, домены, агрегаты, репозитории… с чего начать?
В этой статье я хотел бы рассказать о том, как мы меняли подход к оркестрации на нашем стартап-проекте, зачем мы это делали и какие проблемы по дороге решали. Претендовать на уникальность эта статья вряд ли может, но все же думаю, что она может быть кому-то полезна, так как в процессе решения задачи материал собирался нами с приличным скрипом.
Эта статья является переводом материала «TDD: What went wrong or did it?».
В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (TDD мертв. Да здравствует тестирование).
(Disclaimer!) Данная точка зрения не претендует на роль абсолютной истины и является лишь результатом моего опыта, чтения, наблюдений и размышлений.
Думаю многие знают или слышали о принципах и советах в стиле "Программируйте на уровне интерфейсов, а не реализаций". Хотя в теории, данный принцип кажется полезным и его аргументация звучит логично, но при более глубоком анализе оказывается, что предпосылки лежащие в его основе не реалистичны.
Однажды много лет назад я решил почитать "Искусство войны" Сунь Цзы. Ведь это произведение до сих пор является самой влиятельной книгой по стратегии в мире. Его принципы применимы не только в военной сфере, но и в бизнесе, юриспруденции, спорте и даже программном обеспечении. Но когда я открыл его и начал читать, то обнаружил, что он многие его утверждения настолько очевидны и банальны, что о них не имеет смысла даже говорить:
Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion. И сегодня я хотел бы рассказать вам про микросервисы.
Прим. перев.: автор этой статьи — engineering manager из Испании, работающий в цифровой торговой площадке Adevinta, представленной в 16 странах, — делится своими наблюдениями о частых проблемах, которые он встречал у разработчиков микросервисов. Об этих вызовах стоит знать заранее, чтобы не столкнуться с ними тогда, когда их решение может оказаться слишком затратным.
Когда пост Мартина Фаулера о микросервисахЧитать полностью »
