Задачами доклада являются:
1. Кратко изложить все последующие доклады на секции.
2. Дать краткую теорию по предмету для новичков.
3. Обсудить практику с продвинутыми.
4. Озадачить гиков.

На примере сервиса по обработке платежей, Magnetic Pay, я расскажу о специфике разработки финансовых интернет-проектов: формирование требований, выбор средств и способов реализации, подводные камни.

Сталкивались с тем, что требования сложно формализовать и поддерживать актуальность?

Есть много подходов - user story, use case и т.д., но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?

DDD - подход, позволяющий превратить предметную область из темного леса в настоящего друга человека. Единый язык устраняет трудности перевода между заказчиками, аналитиками, командой разработки и тестировщиками и дает возможность верификации модели заказчиком.

Кого хоть раз в жизни не просили в третий, пятый или восьмой раз немного изменить уже готовую функциональность, потому что заказчик вместе с аналитиками что-то там изначально недодумал? А тут еще менеджеры, вернувшиеся с тренингов или прочитавшие книгу по SCRUM, заставляют каждое утро и каждую неделю проводить какие-то ритуалы, отчитываясь у доски или всей толпой обсуждая задачи, которыми именно вы точно не будете заниматься...

Варианта тут в общем, как это часто бывает - всего два. Продолжать жить как есть, уповая на то, что люди вокруг наконец образумятся, либо взять и образумить их самому.

О том, как это сделать и чтобы еще никто не пострадал, и будет доклад.