Ця подія завершилася!
Go meetup #18
Ідіть на зустріч №18
Подія від: Prague Golang Meetup
Місце проведення: Pure Storage, Rohanské nábřeží 661, Praha 8
Про подію
**Хостинг Pure Storage**
Зверніть увагу, що в офісі Pure Storage усі учасники зустрічі повинні будуть підписати загальну угоду про нерозповсюдження, яка використовується для всіх відвідувачів офісу, щоб мати змогу відвідати зустріч.
Двері відкриті з 17:30, переговори почнуться о 18:00, у нас 3 переговори.
**1\. Вілібальд Ванча \(Чисте зберігання\)\, Вступ до архітектури на основі клітинок**
**2\. Мілош Смолка\, Вбивство спадщини та інші історії CQRS**
Чи знайоме вам відчуття, коли ваш проект застряє, і ви не можете рухатися вперед? Ви бачите кілька виходів, але всі здаються однаково поганими. Ви починаєте думати, чи проект приречений, чи вам просто бракує спеціальних знань. Я відчував це найбільше, коли намагався відійти від застарілих систем, але це часто зустрічається в багатьох проектах.
З часом я зрозумів, що зміна вашої ментальної моделі може виявити рішення, якого ви раніше не бачили. Озираючись на деякі зі своїх проектів, я зрозумів, що одним із шаблонів, який допоміг мені думати по-іншому, був CQRS. Неважливо, чи використовували ви CQRS раніше, оскільки я не планую втомлювати вас абстрактними визначеннями. Про теорію CQRS сказано багато. Натомість я хочу показати, як я використовував це на практиці. Я поділюся трьома реальними історіями з різних компаній і проектів, де мені вдалося просунутися вперед і краще зрозуміти CQRS. Один із них був найскладнішим: знищити застарілу кодову базу.
**Біографія:** Мілош Смолка пише про Go, сучасне програмне забезпечення для бізнесу, і пов’язані теми на [https://threedots.tech](https://threedots.tech/). Йому подобається ділитися тим, чого він навчився, працюючи в стартапах і створюючи продукти в різних сферах.
**3\. Роберт Лащак\, Переосмислення дизайну, орієнтованого на домен, у Go: від міфів до зменшення складності проекту**
Поділ проблем на менші може бути хорошою стратегією для вирішення складних проблем. Але іноді замість того, щоб пришвидшити розвиток проекту, відбувається навпаки. Зрештою, розробка найпростішої функції вимагає героїчної роботи 10 команд над дюжиною мікросервісів протягом півроку. Звучить знайомо?
«Розділяй і володарюй» — не єдина стратегія, яку ми можемо реалізувати в складних проектах. Одним із найвідоміших підходів, який може спростити реалізацію функціональних можливостей із складною логікою домену, є проектування, кероване доменом (DDD).
Я знайшов DDD дуже корисним у багатьох проектах зі складними доменами, над якими я міг працювати. З іншого боку, я знаю, що люди вірять у багато міфів про DDD, який використовується в Go. Більшість із них походить від використання DDD у проектах, які не потребують такого складного підходу, або від проектів, реалізованих людьми, які не розуміли принципів DDD.
Під час цієї доповіді я демістифікую DDD і наведу вам реальний приклад того, як розширення можливостей DDD допомогло спростити їх і збільшити швидкість розробки.
Якщо ви зараз не працюєте над проектом із складною логікою домену, ця презентація все одно може бути корисною для вас, якщо ви захочете працювати над більш складними проектами в майбутньому. Я також дам вам кілька підказок щодо того, з яких частин DDD вам слід починати та які техніки добре працюють із DDD.
**Біографія:** Я веду блог на threedots.tech. Автор «Go With The Domain» і [Watermill.io](https://watermill.io/).
Мій досвід програмування триває 16 років, протягом яких я вивчав різні сфери, зокрема інфраструктуру, глобальні фінансові платформи та безпеку. Пару років тому я нарешті знайшов мову, яку любив: Go.