Агрегаты

Моделирование лишних связей

Самой распространённой ошибкой является добавление лишних ссылок между объектами. Предельный случай этой ошибки - модель связного графа объектов.

Но и в контексте проектирования агрегатов можно внести в модель лишние связи. Чаще всего причинами внесения лишних связей являются:

Но напомню, что единственной причиной добавления ссылки на объект является вхождение объекта в агрегат, а единственной причиной включения объекта в агрегат является его участие в обеспечении инварианта. Поэтому если связь не требуется для обеспечения инварианта, то её включение необходимо дважды обдумать. Потому что, как я уже говорил, лишние связи ведут к повышению …​кхм…​ связанности дизайна и как следствие усложнению системы и деградации производительности.

Анемичная доменная модель

Ещё одной распространённой ошибкой является анемичная доменная модель. Анемичная доменная модель характеризуется в первую очередь сущностями, у которых все свойства доступны для чтения и записи через геттеры и сеттеры. При этом всё поведение сущности ограничивается геттерами и сеттерами. Эта ошибка ведёт к утери возможности обеспечить соблюдение инвариантов.

Кроме того, последствием анемичной модели становится погребение существенных для агрегата трансформаций в методах сервисов приложения. Что влечёт за собой жёсткую сцепку трансформаций и ввода-вывода. Из-за чего:

Давайте сравним решения одной и той же задачи с помощью анемичной и "полнокровной" доменных моделей.

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

Требования к системе следующие:

Так же есть ограничение на API системы: обновление информации осуществляется посредством отправки клиентом списка активных в данный момент пар и их гридов.

Реализация этой задачи с анемичной доменной моделью будет выглядеть примерно так:

data class Grid(
    var name: String,
    var profit: BigDecimal
)

data class SymbolTrading(
    var symbol: String,
    var grids: MutableList<Grid>,
    var activeGrid: Grid?
)

data class CustomerTradings(
    var customerId: Long,
    var tradings: MutableList<SymbolTrading>
)

data class ActiveSymbol(
    var symbol: String,
    var gridName: String
)

fun fetchCustomerSymbols(id: Long): CustomerTradings = TODO()

fun saveCustomerSymbols(customerSymbols: CustomerTradings): Unit = TODO()

fun updateCustomerSymbols(customerId: Long, activeSymbols: List<ActiveSymbol>) {
    val customerSymbols = fetchCustomerSymbols(customerId) // (1)

    activeSymbols.map { activeSymbol ->
        val trading = customerSymbols.tradings.find { it.symbol == activeSymbol.symbol }
        if (trading != null) { // (2)
            trading.activeGrid = trading.grids.find { it.name == activeSymbol.gridName } ?: Grid(activeSymbol.gridName, BigDecimal(0))
        } else {
            val activeGrid = Grid(activeSymbol.gridName, BigDecimal(0))
            customerSymbols.tradings.add(
                SymbolTrading(activeSymbol.symbol, mutableListOf(activeGrid), activeGrid)
            )
        }
    }

    saveCustomerSymbols(customerSymbols) // (1)
}

Такую реализацию будет относительно сложно протестировать - надо будет либо сетапить и проверять состояние БД, либо использовать моки и делать тесты хрупким и зависящим от деталей реализации.

Также здесь в одном методе смешаны и работа с БД (1) и бизнес-правила (2).

Эти две проблемы можно решить посредством вынесения бизнес-правил в утилитарный метод. Однако это не решит основную проблему - с таким подходом невозможно защитить инварианты. Ничего не остановит клиентский код от удаления активного грида из trading.grids. Как и от изменения статистики по неактивному гриду.

Для того чтобы защитить инварианты, необходимо большую часть логики перенести в доменную модель. Также необходимо исключить возможность неконтролируемых операций записи.

Если оставаться в парадигме изменяемой модели данных, то это можно сделать путём сокращения области видимости сеттеров до внутренней в случае Котлина. Но тогда придётся выделять агрегаты в разные модули, что очень не удобно.

В том числе (но не только) по этому, я рекомендую пойти простым путём: сделать сущности неизменяемыми, с закрытым конструктором и опубликованным фабричным методом вместо него, который будет гарантировать соблюдение инвариантов.

typealias Symbol = String

typealias GridName = String

data class Grid(
    val name: GridName,
    val profit: BigDecimal = BigDecimal(0)
)

data class SymbolTrading private constructor(
    val symbol: Symbol,
    val grids: Map<GridName, Grid>,
    val activeGrid: GridName
) {
    init {
        require(activeGrid in grids) { "Active grid ($activeGrid) should be within symbol's grids ($grids)" }
    }

    companion object {
        fun new(symbol: Symbol, gridName: GridName) =
            SymbolTrading(symbol, mapOf(gridName to Grid(gridName)), gridName)
    }

    fun activateGrid(gridName: String): SymbolTrading =
        if (gridName in grids) SymbolTrading(symbol, grids, gridName)
        else SymbolTrading(symbol, grids + (gridName to Grid(gridName)), gridName)

}

data class CustomerSymbols(
    val customerId: Long,
    val tradings: Map<Symbol, SymbolTrading>
) {

    fun activateSymbols(activeSymbols: List<ActiveSymbol>): CustomerSymbols {
        val updatedTradings = activeSymbols.map {
            tradings[it.symbol]?.activateGrid(it.gridName)
                ?: SymbolTrading.new(it.symbol, it.gridName)
        }

        return CustomerSymbols(customerId, tradings + updatedTradings.associateBy { it.symbol })
    }

}

data class ActiveSymbol(
    val symbol: String,
    val gridName: String
)

fun fetchCustomerSymbols(id: Long): CustomerSymbols = TODO()

fun saveCustomerSymbols(customerSymbols: CustomerSymbols): Unit = TODO()

fun updateCustomerSymbols(customerId: Long, activeSymbols: List<ActiveSymbol>) {
    val customerSymbols = fetchCustomerSymbols(customerId)
    val updatedCustomerSymbols = customerSymbols.activateSymbols(activeSymbols)
    saveCustomerSymbols(updatedCustomerSymbols)
}

Такая реализация гарантирует, что любые модификации в данных должны будут пройти через CustomerSymbols. А так как CustomerSymbols является единицей работы с БД, это гарантирует, что в БД не попадут никакие данные в обход кода контроля инвариантов в модели.

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

Наконец, вся бизнес логика, которую надо покрыть полноценным набором тестов, ушла в чистую доменную модель которую очень легко тестировать. А код с эффектами - updateCustomerSymbols - стал тривиальным и его достаточно протестировать одним интеграционным, е2е или сценарным тестом.

Всё вместе - гарантия соблюдения инвариантов, упрощение анализа операций записи и упрощение тестирования - позволяет существенно уменьшить количество ошибок и регрессий и, как следствие, сократить стоимость разработки в длительной перспективе.

Как программировать связи?

Связи внутри агрегата программируются свойствами со ссылками на объекты (a), а между агрегатами - свойствами с идентификаторами корней агрегатов (b):

data class Report(
    val reportingPeriods: List<ReportingPeriod>, // (a)
    val authorId: Long // (b)
)

Как защитить инварианты?

Для того чтобы гарантировать сохранность своих инвариантов, агрегат должен не позволять внешним клиентам менять состояние напрямую. Для достижения этого необходимо следовать принципу "Tell Don’t Ask". В случае агрегатов это означает предоставление корнем агрегата API внесения изменений вместо API получения изменяемых объектов внутренних сущностей.

При этом для получения информации об агрегате есть несколько подходов:

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

Как реализовать выборку данных для UI?

Существует несколько походов, и у каждого из них свои плюсы и минусы.

Варианты 1-3 подробно рассмотрены в книгах по DDD, вариант 4 хорошо описан в посте Лукаса Едера Stop Mapping Stuff in Your Middleware. Use SQL’s XML or JSON Operators Instead

Я сейчас в качестве варианта по умолчанию использую первый, а третий или четвёртый задействую в "горячем" коде. Второй вариант я пока что ни разу не использовал.

Зачем объединять сущности в агрегаты?

Для того чтобы обеспечить выполнение инварианта, затрагивающего несколько сущностей. Частым примером такого инварианта являются слабые сущности - сущности область жизни которых ограничена областью жизни другой сущности.

Почему агрегаты должны быть маленькими?

Из соображений производительности. Так как агрегаты являются единицей персистанса, большие агрегаты приведут к передаче больших объёмов данных по сети. И так как агрегаты являются единицей согласованности, большие агрегаты приведут к "большим" транзакциям (по количеству затронутых объектов и длительности), что повлечёт за собой большое количество конфликтующих транзакций. Это, в свою очередь, станет причиной либо ошибкам согласованности, либо большим накладным расходам на синхронизацию транзакций.

Когда не стоит объединять сущности в агрегаты?

Тогда, когда это приведёт к большим агрегатам. Например, пользователя, его фото и его комментарии лучше разделить по разным агрегатам, не смотря на то, что фото и комментарии являются слабыми сущностями. Фото - просто в силу большого размера. Комментарии - в силу их неограниченного роста.

Когда можно включать в агрегат много видов сущностей?

Агрегат может включать много видов сущностей, при соблюдении двух условий:

Почему в транзакции можно менять только один агрегат?

Во-первых - по определению. Агрегат определяет границы согласованности.

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

В-третьих, агрегаты могут храниться на разных машинах. А по определению агрегата это значит, что придётся иметь дело с распределёнными транзакциями. С которыми я бы предпочёл иметь дело в последнюю очередь.

Как обеспечить выполнение принципа "модификация одного агрегата в одной транзакции"?

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

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

Если же модификации могут быть согласованными в конечном итоге, то операцию необходимо разбить на две. Для этого надо разбить код на два транзакционных метода в слое сервисов приложения. Затем либо оба этих метода публикуются для клиентов, либо они связываются через публикацию доменного события первым методом и его обработку вторым.