Статьи

Разработка DSL для описания архитектуры программного обеспечения (часть 3)

Сентябрь 1, 2017

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

// File layering.arc
exposed artifact UI 
{ 
    include "**/ui/**"
    connect to Business 
} 
exposed artifact Business 
{ 
    include "**/business/**"
    connect to Persistence 
 
    interface default
    {
        // Only classes in the "iface" package can be used from outside
        include "**/iface/*"
    }
} 
artifact Persistence 
{ 
    include "**/persistence/**" 
}
exposed public artifact Model
{
    include "**/model/**"
}

Этот пример также показывает особенность нашего DSL. Вы можете переопределить интерфейс по умолчанию, если хотите ограничить входящие зависимости подмножеством элементов, назначенных для артефакта. Наш слой «Бизнес» теперь доступен только через классы в пакете «iface».

Теперь давайте добавим несколько бизнес-модулей:

// File modules.arc
artifact Customer
{
    include "Customer/**" // All in module "Customer"
    apply "layering"
    connect to Core
}
artifact Product
{
    include "Product/**" // All in module "Product"
    apply "layering"
    connect to Core
}
artifact Core
{
    include "Core/**" // All in module "Core"
    apply "layering"
}

Здесь «Клиент» и «Продукт» связаны с «Ядром». Мы использовали самый простой способ соединения этих артефактов, что означает, что все элементы в «Заказчике» или «Продукте» могут использовать все в интерфейсе по умолчанию «Базового». Поскольку мы переопределили интерфейс по умолчанию «Business», это не все в «Core». Стандартный интерфейс «Core» экспортирует все стандартные интерфейсы не скрытых вложенных артефактов, что означает, что ограничения, определенные в «Business», соблюдаются окружающими артефактами.

Тем не менее, этот способ соединения артефактов не дает нам достаточного контроля. Например, «Product.Model» теперь может получить доступ к «Core.UI» — не очень. Это означает, что нам нужно приложить немного больше усилий для подключения:

// File modules.arc
artifact Customer
{
    include "Customer/**" // All in module "Customer"
    apply "layering"
 
    connect UI to Core.UI, Core.Controller, Core.Model
    connect Controller to Core.Controller, Core.Model
    connect Model to Core.Model
}
artifact Product
{
    include "Product/**" // All in module "Product"
    apply "layering"
 
    connect UI to Core.UI, Core.Controller, Core.Model
    connect Controller to Core.Controller, Core.Model
    connect Model to Core.Model
}
artifact Core
{
    include "Core/**" // All in module "Core"
    apply "layering"
}

Теперь мы более конкретно о деталях нашей связи. Обратите внимание, что мы можем подключаться только к «UI», «Controller» и «Model» из «Core», потому что мы пометили эти артефакты как выставленные . В противном случае они будут заключены в капсулу и не будут напрямую доступны. Слой «Постоянство» не выставлен и поэтому может использоваться только изнутри его окружающего артефакта.

Представляем схемы подключения

Если вы посмотрите внимательно, то обнаружите, что оба блока подключения в «Заказчике» и «Продукте» абсолютно идентичны. Теперь представьте, что вам нужно было соединить десятки артефактов таким образом. Это было бы довольно раздражающим и подверженным ошибкам. Чтобы избежать такого дублирования, мы добавили концепцию схем соединений:

// File modules.arc
connection-scheme C2C
{
    connect UI to target.UI, target.Controller, target.Model
    connect Controller to target.Controller, target.Model
    connect Model to target.Model
}
 
artifact Customer
{
    include "Customer/**" // All in module "Customer"
    apply "layering"
 
    connect to Core using C2C
}
artifact Product
{
    include "Product/**" // All in module "Product"
    apply "layering"
 
    connect to Core using C2C
}
artifact Core
{
    include "Core/**" // All in module "Core"
    apply "layering"
}

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

Это завершает эту серию статей. Если вы хотите попробовать новый язык на свой собственный проект , пожалуйста , заявку на бесплатную пробную лицензию на Sonargraph-Explorer .

Новый язык также станет частью нашего следующего основного выпуска Sonargraph-Architect , который запланирован на ноябрь 2015 года. Если вы в настоящее время используете Sonargraph 7, возможно, будет хорошей идеей ознакомиться с концепциями этого языка. По запросу мы бесплатно перенесем вашу существующую модель архитектуры Sonargraph-7, если у вас есть активный контракт на поддержку.

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

29
Share: