Карьера в Domain driven development для инженеров

Последнее сообщение
Antalik 1710 18
Янв 14

Коллеги,
есть на сайте программисты которые практикуют DDD? Раскажите чем занимаетесь.

yoyoyo 135 12
Янв 14 #1

Антон, если я правильно помню, с технической точки зрения ДДД это просто набор архитектурных паттернов плюс всевозможные кодогенерации и АОР, в двух словах - редкая мутотень используемая в основном во всевозможных ынтырпайзах (особенно финансисты любят такое) , где основной принцип чем непонятней, тем дороже, а чем дороже, тем лучше. Сейчас вроде поутих интерес к подобным вещам. В нефтегазе с этим не встречался никогда.

Antalik 1710 18
Янв 14 #2

Программист и тем более архитектор из меня никакой но насколько я понимаю это патерт для работы уровня бизнес логики в приложениях.

Условно говоря есть 4 подхода к организации бизнес логике в приложении:

  1. UI Driven,Procedural - Transaction Sript. Простой и процесуальный. Условно когда есть функция (метод) на каждую операцию взаимодействия с юзер интерфейсом. Но посути это не ООП. Основные риски - это много дублирования в коде, нарушение принципа единственной обязанности и смешивания с уровнем доступа к данным, и соответсвенно по мере роста становиться все трудней поддерживать и добавлять новый функционал.
  2. Data Driven - Table Module. Классы в бизнес логике предствляют таблиц в базе данных. То есть уровень data access в архитектуре определяет структуру классов в бизнес логике. Пишут что это в основном в legacy code.
  3. Data Driven - Active Record. Каждый экземпляр класса - это ряд таблице базы данных. В классе есть логика работы с базой данных, как сохранить, поменять и тд. Каждый класс можно расширить методами бизнес логики. По сути модули объектов отражают структуры базы данных.  Плюсы: быстрая реализация простых приложений. Риск - по мере роста приложения, так как классы твердо завязаты на структуру базы данных, то нельзя оптимизировать работу бизнес логики и структуры базы данных по отдельности - какая получилось такая и получилось.  По определению нарушается принципа единственной обязанности - так как бизнес логика и уровень доступа данным склеины. Это выливается в сложности с тестированием (unit testing).
  4. Business Driven - Domain Driven Design. На дизайн классов и логику решения задачей бизнеса ни влияет ни уровень доспута к данным, ни уровень презентации. Классы больше всего отражают объекты бизнеса, язык пользователей, и условно говоря физику процессов. Это там где для дизайна объектов привлекают пользователей и специалистов отрасли (domain). Бизнес логика приложения главенствует в архитектуре - соответсвенно под бизнес логику подстраиваются другие уровни в приложении (Data, Service, Presentation). Одни плюсы в архитектуре, но это самый долгий и дорогой процесс разработки.

Сообственно 10 лет проработав как reservoir engineer - накопил какие-то знание (domain knowledge), последние время увлекся программированием (как product owner прежде всего), условно говоря в своем плагине я занимаюсь "бизнес логикой" - сами фунциии (static class), а вся обертка этих функций в Excel это уже другой уровень (презентакция) в "архитектуре". Прелесть в том что если есть в архитектуре приложения четкое выделение бизнес логики, и она не зависит от других уровней, то её можно использовать в других приложениях. Вот например калькуляторы используют туже самую библеотеку что и плагин.

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

Интересно услушать про таких перебежчиков, чем люди занимаются, как туда попали.
 
 

yoyoyo 135 12
Янв 14 #3

Антон, попробую изложить свой небольшой опыт в этой области. Нет сомнений, что архитектура приложения, особенно большого приложения, вещь очень важная, и ошибки допущенные на этапе проектирования очень дороги и часто непоправимы. Те подходы к проектированию, которые Вы описали, относятся скорее к компетенции системного архитектора, product owner-ы такими вещами обычно не занимается. Плюс на сегодняшний день для каждого из подходов существет куча framework-ов, вручную сейчас никто не пишет такие вещи, так что стоит еще задача выбора подходящего инструмента, что тоже не всегда просто. Еще скажу, что на мой взгляд Data Driven/Business Driven  design-ы обычно применяются при разработки громоздких, распределенных (чаще всего банковских) систем. Я много лет работал в компании www.emc.com , одного из самых крупных разаработчиков систем хранения, так вот, там мы никогда не приминяли подобные вещи по ряду причин.

Те подходы, которые Вы приминяете при разработке своего проекта, это стандартное разделение интерфейса от бизнес логики. Вещь очень правильная и нужная. Тут тоже есть много подходов, можете посмотрет в сторону Model–view–presenter или Model–view–controller. Вот есть любопытная статья от гугла - http://www.gwtproject.org/articles/mvp-architecture.html Но она наверно требует представление о Гугл Вэб Тулкит. Так что, на вашем месте я бы особо не лез в сторону Business Driven design, хотя если хочется, можете почитать http://martinfowler.com/books/eaa.html 

Еще несколько слов личного опыта разаработки софта для нефтяной промышленности. Я работал на SPT Group, это те которые MEPO делают, так вот, процесс разаработки там выглядел примерно так. У нас была группа product owner-ов с reservoir engineer бэкграуном. Они определяли какая функциональность должна присутсвовать в продукте. В код они даже не заглядывали. После того как они определяли требования, программисты начинали реализовывать задуманное, время от времени обращаясь к reservoir engineer-ам за советом как лучше реализовать такую-то фичу или визуализировать такие-то данные. Ничего сложного как видите. В других проектах (OLGA) компании, все тоже самое насколько я помню.

 

Antalik 1710 18
Янв 14 #4

yoyoyo пишет:

Еще несколько слов личного опыта разаработки софта для нефтяной промышленности. Я работал на SPT Group, это те которые MEPO делают, так вот, процесс разаработки там выглядел примерно так. У нас была группа product owner-ов с reservoir engineer бэкграуном. Они определяли какая функциональность должна присутсвовать в продукте. В код они даже не заглядывали. После того как они определяли требования, программисты начинали реализовывать задуманное, время от времени обращаясь к reservoir engineer-ам за советом как лучше реализовать такую-то фичу или визуализировать такие-то данные. Ничего сложного как видите. В других проектах (OLGA) компании, все тоже самое насколько я помню.

 

Ну когда есть команда, то да Product Owner пишет требования. Когда ты сам себе режесёр и работаешь максимус с одним программистом фрилансиром, то понемногу вовлекаешься во все области.

А как вы в SPT group оказались?

RomanK. 2143 16
Янв 14 #5

В MView начал использовать Model-View-Presenter, раньше писал обычный лапша-код, так как раньше писал только "одноэкранные" приложения. Испытываю удовольствие перфециониста - визуальная часть отделена от логики и как раз сейчас я отказываюсь от MDI интерфейса, всё что мне понадобится это переделать UI и внести минимальные изменения в код. Я нацеливаюсь на большое, масштабируемое приложение.

yoyoyo 135 12
Янв 14 #6

Antalik пишет:
А как вы в SPT group оказались?

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

volvlad 2196 18
Янв 14 #7

Antalik пишет:
А как вы в SPT group оказались?

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

yoyoyo 135 12
Янв 14 #8

Надо было соглашаться Владимир! Мне бы было не так тоскливо там. Вам в Дании нравится?

ProMan 519 14
Янв 14 #9

yoyoyo пишет:
Случайно забрел на их сайт, увидел, что им нужны программисты, послал резюме, пособеседовался и так получилось, что мне сделали оффер. Интересный был опыт и работы и жизни
 
Так МЕРО это частично твое творчество? )
Приходилось сталкиваться. Хорошая программа для адаптации моделей, полезная для разработчиков. Как то не по человечески дизайн, в смысле не итуитивно все. Пока разобрался что есть что подоспела новая 4 версия. Такое ощущение что все переписали заново код. Но в плане практичности использования и автоматизации процессов построен софт хорошо. Так ты уволился? Не понравилось жить в Норвегии? Раскажи про внутрению "кухню", сильные, слабые стороны SPT, интересно знать чисто с технической точки зрения, если конечно не конфидициальная информация.
 

yoyoyo 135 12
Янв 14 #10

ProMan, да в последней версии много чего переписали, должно быть меньше глюков. Коллектив был хороший, грех жаловаться. Я недавно по ряду причин вернулся в Питер, в Норвегии жизнь очень специфическая, много народу уезжает в итоге. После покупки СПТГруп шлюмами видимо будут какие-то изменения, точнее даже я уже застал первые изменения - начали приезжать какие-то странные люди вешать лапшу про то, как всем нам повезло, появились интернет тренинги по безопасности (типа увидел что лэптоп коллеги без присмотра - надо срочно стукануть в службу безопасности) и все такое. А внутренняя кухня, даже не знаю, компания как компания, ничего особенного.

volvlad 2196 18
Янв 14 #11

yoyoyo пишет:
Надо было соглашаться Владимир! Мне бы было не так тоскливо там. Вам в Дании нравится?

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

visual73 1945 17
Янв 14 #12

Копенхаген красивый город, я тама был в 2002-ом в компании Calsep ))) пил пыво Карлсберг разливное )))

Go to top