«Обычный DDD», часть 5: доменно-ориентированная архитектура

Архитектура

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

Как мы все знаем, в истории человеческой науки при обсуждении того, как устроена Вселенная, было два университета, которые сказали:геоцентрический"и"гелиоцентрическая теорияСегодня все мы знаем, что гелиоцентрическая теория научна, что Земля и планеты вращаются вокруг Солнца, и, надо полагать, детсадовцы тоже знают, что это элементарный здравый смысл.Однако сотни лет назад настаивание на гелиоцентризме могло караться смертной казнью..

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

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

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

Итак, как изменилась точка зрения людей, смотрящих на архитектуру, от архитектуры, ориентированной на данные, к архитектуре, ориентированной на предметную область? Причин может быть много, ветеран индустрии, автор книги «Agile Software Development»Роберт С. Мартин (дядя Боб)Однажды сказал что-то:

The first concern of the architect is to make sure that the house is usable, it is not to ensure that the house is made of brick.

Дядя взял в пример архитектора, строящего дом. Что для архитектора важнее всего при строительстве дома? Материал кирпич или дерево? Явно нет, для дома самое главное, что он должендоступный,Этофундаментальный.Иначе зачем его строить? Что касается того, какие материалы использовать и какой стиль отделки выбрать, это простодеталь.

Этот пример включает два важных понятия в архитектуре, а именноСущественныйиДеталь. В архитектуре, если вы не можете понять, что является фундаментальным, а что просто деталями, и не можете поставить их в нужное место, то это равносильноПоставь телегу впереди лошади. Для дома "удобство использования" имеет основополагающее значение, "кирпичи" и "украшения" - лишь детали его реализации.Кроме кирпичей, можно использовать и дерево! Точно так же и для автомобиля «надежность и безопасность» — это его основа, а электрический он или топливный — это просто другая его реализация.

Итак, оглядываясь назад на архитектуру программного обеспечения, ориентированную на данные, проблема в том, что она неверна.фундаментальный.В архитектуре предприятия "Бизнес-логика"является основой. В качестве метода хранения база данных представляет собой лишь определенный тип бизнес-данных.деталь, у него могут быть разные реализации, могут использоваться реляционные базы данных, NoSQL и даже файловые хранилища.Следует отметить, что это не означает, что данные не важны, но, по сути, архитектура — это управление сложностью, а не управление данными..Очевидно, что в большинстве корпоративных архитектур сложная бизнес-логика находится в центре внимания управления..

Итак, это породилоДоменно-ориентированная архитектура.

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

Конечно,Архитектура, ориентированная на предметную область, — это всего лишь идея, а идеи должны иметь разные реализации, и DDD — одна из них.. В следующей статье мы представимШестиугольная архитектураиЛуковая АрхитектураКак реализовать доменно-ориентированную архитектуру.


Обратите внимание на общедоступную учетную запись [MetaThoughts] и своевременно получайте уведомление об обновлении статей колонки.