Любая последовательность событий, в которой мы принимаем участие ощущениями, восприятиями и, возможно, действиями, постепенно выпадает из сверы сознания, когда одна и та же череда событий многократно повторяется. Но она немедленно выстреливается в сознательную область, как только в процессе повтора или событие, или окружающие условия отличаются от тех, которые встечались во всех предыдущих случаях.
[...]
Мы идем привычным путем в мастерскую, переходим дорогу в знакомых местах, сворачиваем в переулки и т.д., в то время как мысли наши витают очень далеко. Но как только ситуация проявляет релевантный дифференциал — скажем, дорога кончается втом месте, где мы ее всегда переходим, так что нам приходится идти в обход — этот дифференциал и наша реакция на него вторгаются в сознание, из которого, впрочем, они быстро уходят, если дифференциал начинает повторяться.
Изначально «хорошим» и «плохим» являются оценки ощущений. На их базе формируются страхи «плохого» и предвкушения «хорошего». Поскольку эти страхи и предвкушения сами являются оценками и создают состояние «хорошо – плохо», то на их базе формируются и страхи страхов и предвкушения предвкушений.
Привязанность есть то, что сопровождает удовольствие.
Есть вещи, которые доставляют нам удовольствие, и наш ум испытывает тягу к ним. Тяготение ума к центру удовольствия и называется привязанностью. Мы никогда не привязываемся к тому, что не доставляет нам удовольствия. Другое дело, что подчас мы находим удовольствие в вещах, достаточно странных, но тем не менее сохраняется все тот же принцип: что дает нам удовольствие, к тому мы и привязываемся.
Отвращение есть то, что сопровождает страдание. Мы стараемся немедленно отдалиться от того, что причиняет нам страдание.
Из своего опыта — лет 5 назад работал в торговой компании. Продукты из категории AX (A — небольшая группа товаров которые дают до 50% прибыли, X — по которым возможно более-менее точное прогнозирование) давали примерно 10% оборота (или даже меньше). Это в целом по фирме — а она была с филиальной структурой. В результате статистическое прогнозирование теряло всякий смысл. Я думаю, это типичная ситуация на рынке — отсюда всякие CRM системы и прочее (самая прибыльная группа была — AZ — то есть «эксклюзив» — то что только под заказ везется).
А прибавьте наши реалии — когда можно купить китайскую «продукцию». Размер партии почти всегда очень большой и поставки редкие. Казалось бы — должно быть «замораживание» средств и неликвиды всякие — но поскольку цена (себестоимость) минимальная а кроме китайского ничего нигде нет — разгребают и его. Какая уж тут математика.
А если кроме шуток — то что у вас есть — это опыт самостоятельной работы — то есть вообще самостоятельной. Точнее даже не просто работы — а реального выполнения задач. Это то, чего нет у многих, кто работает в IT конторах.
А так — поддерживаю сказанное выше:
— читайте книги
— изучайте исходные коды
— выучите еще один язык (или не один)
— пойдите работать в IT компанию
В свое время писал отталкиваясь от данных, несколько лет писал по книжкам DDD, даже считал это подход вполне адекватным. Но — полезно знать много технологий, чтобы сравнивать и делать выводы. Разработка набора entity в DDD и разработка таблиц БД практически не отличаются по сути — как я уже выше сказал — модель базы данных раньше и называлась ER диаграммой (Entity relationship). А процесс разработки этих самых entity начинается с анализа того, что происходит в бизене — то есть с процессов. Я не заметил в DDD методике фокуса на процессы — во всей книжке Эванса нет ни одной activity диаграммы или workflow.
Да, так что я хотел сказать. Из тех технологий, с которыми я работаю, программные сущности больше всего отвечают реальным сущностям в такой штуке как OLAP кубы. В базе данных может быть legacy структура таблиц, по большому счету руководству предприятия плевать какие там классы в программе. Но когда менеджер таскает dimensions и measures в сводной таблице excel — они не могут не соответствовать его бизнесу — иначе он не поймет данных отчета.
Многое в ООП — это не плохо, но это чисто инфраструктурные вещи и ошибка полагать что DDD помогает лучше понять или отобразить предметную область — это просто еще одна разрекламированная patterns and practices.
C# замечательный язык. Но, не все удобно в области ФП: new Dictionary<string, Func<string, string, Expression<Func<MyEntity, bool>>>>
это из реального проекта.
В старые времена, когда не было такого термина «Code First» мы разлагали предметную область на таблицы БД и связи между ними — это называлось ER диаграммами. Обратите внимание, что в большинстве, как мне кажется, систем, таблицы и классы-entity мапятся один к одному. Так что, когда вы разлагаете предметную область на entity, это не ООП, точнее не обязательно ООП.
Вы упомянули о бизнес-процессах. Есть такой «процессный подход к управлению», я думаю вы знаете об этом, был популярен в консалтинге какое-то время назад (может и сейчас). Там в основе всего – процессы (процесс Заказа, процесс Отгрузки и т.п.). Такие вещи, как записи в базе данных или бумажные документы, считаются артефактами процесса. В связи с использованием ООП (и других частных методологий типа DDD) внимание сместилось в сторону артефактов (1С, например, называет себя «документо-ориентированной» системой). В результате в системе вы можете найти таблицу «Заказ», но вы нигде не найдете «Процесса Заказа», он размазан по всей системе.
И еще важный момент — модель (не смотря на спекулятивное использование этого термина) — это не entity — это некий набор алгоритмов, функций.
Самое интересное — почему стал возможен такого рода пост. Почему никто не говорит «долой функциональное программирование» к примеру. Как было сказано в посте — это была разрекламированная вещь. Некий продукт мог иметь в 90-е «конкурентные преимущества» уже только потому, что на коробке было написано «ООП». Да и сейчас, если вы устраиваетесь на работу в корпоративный сектор, паттерны спрашивают как катехизис на собеседовании. В этом что-то есть от сетевого маркетинга.
Так вот — оглянитесь, и вы увидите много таких вещей вокруг, доверие к которым гораздо выше, чем это может быть при рациональном подходе. Отсюда холивары в том числе (по ORM, ERP и т.д.)
А что касается самого по себе ООП, я думаю, уже никто не использует его в чистом виде в новых проектах. Посмотрите open source проекты на C# например — очень многие активно используют возможности ФП в C# (как сказано в посте «Такие тяжелые фреймворки быстро умирают и замещаются более легковесными библиотеками и наборами легковесных библиотек»).
Да и многие ООП паттерны — на самом деле реализация тех возможностей, которые есть в ФП из коробки (strategy например). Паттерн Entity-Service-Repository — тоже нельзя назвать чистым ООП: entity слишком плоские, сервисы и репозитории тоже трудно назвать полноценными объектами — скорее контейнерами с процедурами/функциями.
Да — и если животные не обладают сознанием — значит они не испытывают боли, а лишь только «физиологические реакции»
[...]
Мы идем привычным путем в мастерскую, переходим дорогу в знакомых местах, сворачиваем в переулки и т.д., в то время как мысли наши витают очень далеко. Но как только ситуация проявляет релевантный дифференциал — скажем, дорога кончается втом месте, где мы ее всегда переходим, так что нам приходится идти в обход — этот дифференциал и наша реакция на него вторгаются в сознание, из которого, впрочем, они быстро уходят, если дифференциал начинает повторяться.
В. Шредингер. Разум и материя.
Привязанность есть то, что сопровождает удовольствие.
Есть вещи, которые доставляют нам удовольствие, и наш ум испытывает тягу к ним. Тяготение ума к центру удовольствия и называется привязанностью. Мы никогда не привязываемся к тому, что не доставляет нам удовольствия. Другое дело, что подчас мы находим удовольствие в вещах, достаточно странных, но тем не менее сохраняется все тот же принцип: что дает нам удовольствие, к тому мы и привязываемся.
Отвращение есть то, что сопровождает страдание. Мы стараемся немедленно отдалиться от того, что причиняет нам страдание.
© Патанджали, II век до нашей эры.
Из своего опыта — лет 5 назад работал в торговой компании. Продукты из категории AX (A — небольшая группа товаров которые дают до 50% прибыли, X — по которым возможно более-менее точное прогнозирование) давали примерно 10% оборота (или даже меньше). Это в целом по фирме — а она была с филиальной структурой. В результате статистическое прогнозирование теряло всякий смысл. Я думаю, это типичная ситуация на рынке — отсюда всякие CRM системы и прочее (самая прибыльная группа была — AZ — то есть «эксклюзив» — то что только под заказ везется).
А прибавьте наши реалии — когда можно купить китайскую «продукцию». Размер партии почти всегда очень большой и поставки редкие. Казалось бы — должно быть «замораживание» средств и неликвиды всякие — но поскольку цена (себестоимость) минимальная а кроме китайского ничего нигде нет — разгребают и его. Какая уж тут математика.
И еще, вы свой IQueriable интерфейс писали или у вас чистый EF?
А если кроме шуток — то что у вас есть — это опыт самостоятельной работы — то есть вообще самостоятельной. Точнее даже не просто работы — а реального выполнения задач. Это то, чего нет у многих, кто работает в IT конторах.
А так — поддерживаю сказанное выше:
— читайте книги
— изучайте исходные коды
— выучите еще один язык (или не один)
— пойдите работать в IT компанию
И удачи!
Да, так что я хотел сказать. Из тех технологий, с которыми я работаю, программные сущности больше всего отвечают реальным сущностям в такой штуке как OLAP кубы. В базе данных может быть legacy структура таблиц, по большому счету руководству предприятия плевать какие там классы в программе. Но когда менеджер таскает dimensions и measures в сводной таблице excel — они не могут не соответствовать его бизнесу — иначе он не поймет данных отчета.
Многое в ООП — это не плохо, но это чисто инфраструктурные вещи и ошибка полагать что DDD помогает лучше понять или отобразить предметную область — это просто еще одна разрекламированная patterns and practices.
new Dictionary<string, Func<string, string, Expression<Func<MyEntity, bool>>>>это из реального проекта.
Вы упомянули о бизнес-процессах. Есть такой «процессный подход к управлению», я думаю вы знаете об этом, был популярен в консалтинге какое-то время назад (может и сейчас). Там в основе всего – процессы (процесс Заказа, процесс Отгрузки и т.п.). Такие вещи, как записи в базе данных или бумажные документы, считаются артефактами процесса. В связи с использованием ООП (и других частных методологий типа DDD) внимание сместилось в сторону артефактов (1С, например, называет себя «документо-ориентированной» системой). В результате в системе вы можете найти таблицу «Заказ», но вы нигде не найдете «Процесса Заказа», он размазан по всей системе.
И еще важный момент — модель (не смотря на спекулятивное использование этого термина) — это не entity — это некий набор алгоритмов, функций.
вы не могли бы в двух словах — но поподробнее эту мысль раскрыть?
Так вот — оглянитесь, и вы увидите много таких вещей вокруг, доверие к которым гораздо выше, чем это может быть при рациональном подходе. Отсюда холивары в том числе (по ORM, ERP и т.д.)
А что касается самого по себе ООП, я думаю, уже никто не использует его в чистом виде в новых проектах. Посмотрите open source проекты на C# например — очень многие активно используют возможности ФП в C# (как сказано в посте «Такие тяжелые фреймворки быстро умирают и замещаются более легковесными библиотеками и наборами легковесных библиотек»).
Да и многие ООП паттерны — на самом деле реализация тех возможностей, которые есть в ФП из коробки (strategy например). Паттерн Entity-Service-Repository — тоже нельзя назвать чистым ООП: entity слишком плоские, сервисы и репозитории тоже трудно назвать полноценными объектами — скорее контейнерами с процедурами/функциями.