Функциональный способ реализации доменного дизайна
У меня был большой опыт написания доменных приложений с использованием C#. Чем больше приложений я пишу, тем больше я нахожу, что хочу использовать подход, который не очень хорошо подходит для стандартных методов C#/OO:
- Я хочу написать как можно больше чистых функций, потому что их действительно легко протестировать.
- Я хочу написать свою бизнес-логику более декларативным способом.
Поэтому я смотрю на функциональные языки, такие как F#. В конце концов, нет никаких причин, по которым проект, управляемый доменом, должен быть реализован с использованием ОО.
Мне было интересно, есть ли у кого-нибудь какие-либо идеи / опыт в разработке дизайна, ориентированного на домен, с использованием функционального языка. Особенно:
- Как будет выглядеть функциональная модель предметной области?
- Как бы вы абстрагировали слой доступа к данным от модели предметной области?
4 ответа
Отказ от ответственности: у меня есть только смутные знания о дизайне, ориентированном на предметную область, поэтому в ответе могут не использоваться правильные термины, и он может быть чрезмерно сфокусирован на коде, а не на общих понятиях, но в любом случае вот некоторые мысли...
Акцент на понимании предметной области, а не на разработке конкретных функций или объектов для их реализации, кажется очень естественным для того, как люди используют функциональные языки программирования в целом. Очень часто (по крайней мере, в части функционального приложения) вы начинаете с разработки структуры данных, которая описывает (или моделирует) мир, с которым вы работаете. Структура данных отделена от реализации, поэтому она хорошо моделирует домен.
Очень хороший пример описан в статье о составлении финансовых контрактов. Примером является приложение для оценки (и другой обработки) финансовых контрактов. Самое главное, чтобы создать модель контрактов - что они на самом деле? Чтобы ответить на это, авторы проектируют структуру данных для описания контрактов. Что-то вроде:
type Contract =
| Zero // No trades
| Single of string * float // Single trade (buy something for some price)
| And of Contract * Contract // Combine two contracts
| Until of Contract * DateTime // Contract that can be executed only until...
// (...)
Есть несколько других случаев, но структура данных очень проста и моделирует широкий спектр довольно сложных контрактов, которые используются в финансовой индустрии.
Резюме Я думаю, что фокус на структурах данных, которые используются для моделирования мира (и отделены от реализации, которая их использует), очень близок к ключевым концепциям DDD.
Вот пример идиоматической реализации F#: доменно-управляемый дизайн с F# и EventStore
Отказ от ответственности: я автор.
Появилась новая идея использования Clojure (современная версия Lisp), который является функциональным языком, для создания моделей предметной области. Эта презентация является довольно хорошим вступлением (и это также потрясающая демонстрация HTML5).
Короче говоря, функциональное отношение прекрасно в сочетании с Event Sorcing. Это позволяет очень легко создавать полностью тестируемые модели. И если вы не хотите прямо сейчас переходить на совершенно новый язык, современный C# является довольно хорошим языком для написания функционально-подобного кода (по крайней мере, для реализации моделей общих доменов).
Старый вопрос, но на удивление все еще актуален сегодня.
Насколько мне известно, лучшая (только?) Книга о функционально-ориентированном доменном дизайне - это доменное моделирование, сделанное функционально, написанная Скоттом Влащиным, автором F# для развлечения и выгоды (упоминалось выше).
Перед тем, как погрузиться в книгу, поговорим о шаблонах проектирования в функциональном программировании. Это краткое изложение концепций (подсказка: шаблонов нет:)
Примеры приведены на F#, но их легко перевести на любой другой функциональный язык с алгебраическими типами (в моем случае Haskell и PureScript).