Часть1: Построение архитектуры на основе поддержки модели предметной области
Построение архитектуры на основе поддержки модели предметной области
Большинство разработчиков никогда не видели модель предметной области (domain model), только модель данных(data model).
DDD EU 2017
— Cyrille MartraireБольшинство разработчиков, с которыми мы говорим об архитектуре, испытывают мучительное предчувствие, что все можно сделать лучше. И часто пытаясь спасти систему, которая каким-то образом вышла из строя, пытаются ввернуть какую-то структуру в "комок грязи". Они знают, что их бизнес-логика не должна распространяться повсюду, но они не знают, как это исправить.
Мы обнаружили, что многие разработчики, когда их просят спроектировать новую систему, немедленно приступают к построению схемы базы данных, а объектная модель рассматривается как нечто запоздалое. Вот тут-то все и начинает идти наперекосяк. Вместо этого поведение должно стоять на первом месте и определять наши требования к хранилищу. В конце концов, наших клиентов не волнует модель данных. Их волнует, что делает система.; в противном случае они просто использовали бы электронную таблицу.
Первая часть книги посвящена тому, как построить богатую объектную модель с помощью TDD (в [chapter_01_domain_model]), а затем рассмотрим, как уберечь эту модель от технических проблем. Покажем, как создавать код, игнорирующий персистентность, и как создавать стабильные API-интерфейсы вокруг нашего домена, чтобы мы могли проводить агрессивный рефакторинг.
Для этого мы представляем четыре ключевых шаблона проектирования:
Repository pattern, абстракция над идеей постоянного хранения
Шаблон Service Layer четко определяет, где начинаются и заканчиваются наши варианты использования
Unit of Work pattern для обеспечения атомарных операций
Aggregate pattern для обеспечения целостности наших данных
Если вам нужна картина того, куда мы в итоге придем, взгляните на [part1_components_diagram], но не волнуйтесь, если для вас все эта графика не имеет смысла! Мы разберём каждую фигуру изображенную на рисунке, одну за другой, на протяжении всей этой части книги.
Figure 1. Диаграмма компонентов для нашего приложения в конце [part1]Мы также уделим немного времени, чтобы поговорить о coupling and abstractions, проиллюстрировав это на простом примере, который показывает, как и почему мы выбираем наши абстракции.
Три приложения являются дальнейшими целями исследованиями содержания Части I:
[appendix_project_structure] это описание инфраструктуры для нашего примера кода: как мы строим и запускаем образы Docker, где мы управляем информацией о конфигурации и как мы запускаем различные типы тестов.
[appendix_csvs] это своего рода контент типа "proof is in the pudding", показывающий, как легко поменять всю нашу инфраструктуру—API Flask, ORM и Postgres-на совершенно другую модель ввода-вывода, включающую CLI и CSV.
Наконец, [appendix_django] может представлять интерес, если вам интересно, как эти паттерны могут выглядеть при использовании Django вместо Flask и SQLAlchemy.
Большинство разработчиков никогда не видели модель предметной области (domain model), только модель данных(data model).
— Cyrille Martraire
Большинство разработчиков, с которыми мы говорим об архитектуре, испытывают мучительное предчувствие, что все можно сделать лучше. И часто пытаясь спасти систему, которая каким-то образом вышла из строя, пытаются ввернуть какую-то структуру в "комок грязи". Они знают, что их бизнес-логика не должна распространяться повсюду, но они не знают, как это исправить.
Мы обнаружили, что многие разработчики, когда их просят спроектировать новую систему, немедленно приступают к построению схемы базы данных, а объектная модель рассматривается как нечто запоздалое. Вот тут-то все и начинает идти наперекосяк. Вместо этого поведение должно стоять на первом месте и определять наши требования к хранилищу. В конце концов, наших клиентов не волнует модель данных. Их волнует, что делает система.; в противном случае они просто использовали бы электронную таблицу.
Первая часть книги посвящена тому, как построить богатую объектную модель с помощью TDD (в [chapter_01_domain_model]), а затем рассмотрим, как уберечь эту модель от технических проблем. Покажем, как создавать код, игнорирующий персистентность, и как создавать стабильные API-интерфейсы вокруг нашего домена, чтобы мы могли проводить агрессивный рефакторинг.
Для этого мы представляем четыре ключевых шаблона проектирования:
Repository pattern, абстракция над идеей постоянного хранения
Шаблон Service Layer четко определяет, где начинаются и заканчиваются наши варианты использования
Unit of Work pattern для обеспечения атомарных операций
Aggregate pattern для обеспечения целостности наших данных
Если вам нужна картина того, куда мы в итоге придем, взгляните на [part1_components_diagram], но не волнуйтесь, если для вас все эта графика не имеет смысла! Мы разберём каждую фигуру изображенную на рисунке, одну за другой, на протяжении всей этой части книги.
Мы также уделим немного времени, чтобы поговорить о coupling and abstractions, проиллюстрировав это на простом примере, который показывает, как и почему мы выбираем наши абстракции.
Три приложения являются дальнейшими целями исследованиями содержания Части I:
[appendix_project_structure] это описание инфраструктуры для нашего примера кода: как мы строим и запускаем образы Docker, где мы управляем информацией о конфигурации и как мы запускаем различные типы тестов.
[appendix_csvs] это своего рода контент типа "proof is in the pudding", показывающий, как легко поменять всю нашу инфраструктуру—API Flask, ORM и Postgres-на совершенно другую модель ввода-вывода, включающую CLI и CSV.
Наконец, [appendix_django] может представлять интерес, если вам интересно, как эти паттерны могут выглядеть при использовании Django вместо Flask и SQLAlchemy.
Комментарии
Отправить комментарий