Агрегаты / Хабр

Этот материал является кросс-постом из моего блога

Следить за обновлениями блога можно в моём канале: Эргономичный код

Введение

Я считаю, что именно агрегаты из Domain-Driven Design лежат в основе поддерживаемых информационных систем. Однако эта концепция малоизвестна за пределами DDD-сообщества и довольно сложна для понимания, поэтому я решил написать очередной пост посвящённый агрегатам. В основном для чтобы структурировать собственное понимание агрегатов и создать «методичку» для своих команд, но и широкой общественности, я надеюсь, этот пост тоже может быть полезен.

Что такое агрегат? (TLDR)

Агрегат — это кластер сущностей и объектов-значений, объединённых общими инвариантами. Любое взаимодействие с агрегатом осуществляется через одну и только одну из его сущностей, называемую корнем агрегата.

Для того чтобы обеспечить соблюдение инвариантов, агрегат должен удовлетворять следующим требованиям:

1. Выступать единицей персистанса (все сущности всегда загружаются и сохраняются вместе). «Точкой входа» персистанса (загружаемым и сохраняемым объектом) является корень агрегата.

2. Все модификации состояния агрегата должны осуществляться через корень.

3. Все сущности должны входить только в один агрегат.

В объектно-ориентированном коде агрегат всегда материализуется минимум в два класса — корень агрегата и репозиторий агрегата. Внутри агрегата связи реализуются ссылками непосредственно на объекты. Между агрегатами связи реализуются через идентификаторы корней агрегатов.

Например, отчёт с непересекающимися отчётными периодами и составителем моделируется двумя агрегатами, которые на Котлине будут выглядеть так:

// Агрегат составителя отчёта
data class Author(
  val id: Long,
  val name: String
)
interface AuthorsRepo {
  fun save(user: Author): Author
  fun findById(id: Long): Author?
}
// Агрегат отчёта
data class ReportingPeriod(
  val from: LocalDate,
  val to: LocalDate
) {
  init {
    require(from <= to) { "$from > $to" }
  }
}
data class Report(
  val id: Long,
  val reportingPeriods: List<ReportingPeriod>,
  val authorId: Long
) {
  init {
  reportingPeriods. sortedBy { it.from }
    .windowed(2, partialWindows = false)
    .find { it[0].to >= it[1].from }
    ?.let { throw IllegalArgumentException("Report cannot have intersecting intervals: ${it[0]} and ${it[1]}")  }
  }
}
interface ReportsRepo {
  fun save(user: Report): Report
  fun findById(id: Long): Report?
}

Почему агрегата именно два, а не один или три? Ответ на этот вопрос лежит в принципах декомпозиции модели информации системы.

Принципы декомпозиции модели информации на агрегаты

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

1. Агрегаты не должны иметь циклических связей.

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

3. Агрегаты должны обеспечивать соблюдение инвариантов. Агрегаты предоставляют такое API, которое не позволит клиенту перевести модель в невалидное состояние.

4. Агрегаты должны обеспечивать возможность реализовать все операции системы так, чтобы в одной транзакции менялся (или удалялся) один агрегат. Притом речь идёт именно об изменении (в том числе в виде удаления) существующих агрегатов — создавать и читать можно сколько угодно агрегатов.

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

6. Агрегаты должны храниться целиком в одной системе хранения данных на одном узле. Разные агрегаты одной системы могут храниться на разных узлах или в разных хранилищах.

7. Агрегаты могут ссылаться на другие агрегаты только через идентификаторы корней. Внутри агрегата сущности могут свободно ссылаться друг на друга.

Так вот, почему агрегатов всё-таки именно два? Потому что отчёты и составители ценны сами по себе и имеют независимые жизненные циклы. А периоды не имеют смысла без отчёта и инвариант отсутствия пересечения определяется на кластере объектов отчёта и его отчётных периодов.

Методика декомпозиции модели информации на агрегаты

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

Затем я ищу инварианты системы. Самый простой и часто встречаемый инвариант — область жизни одной сущности (А) не должна выходить за пределы области жизни другой сущности (Б). В этом случае сущности А и Б нужно объединить в агрегат с Б в качестве корня.

Но самые важные инварианты определяются конкретными людьми в конкретном контексте и для их выявления не существует универсального алгоритма на базе технических вводных. Чтобы выявить самые важные инварианты я обращаюсь к экспертам — заказчикам, пользователям, владельцам продукта, руководителям проектов,
аналитикам и т. д. Зачастую эксперты самостоятельно не могут сформулировать инварианты, и им необходимо помочь, предлагая свои версии и задавая наводящие вопросы (например, «могут ли пересекаться отчётные периоды?»). Конкретные техники и способы помощи экспертам подробно расписаны в книгах по DDD.

Действительно важные инварианты бизнес так или иначе озвучит — важно их услышать. Если не услышите в процессе разработки, то точно услышите, когда инвариант будет нарушен в промышленной эксплуатации с последствиями для бизнеса:)

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

Затем я проверяю получившиеся агрегаты на соответствие принципам.

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

Что такое диаграмма эффектов?

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

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

1. Если агрегаты всегда меняются вместе и размер позволяет — объединить их в один.

2. Если в одной операции смешались разные ответственности и есть возможность — разбить операцию на две.

3. Если в одной операции смешались разные ответственности, но разбиение операции невозможно или ухудшает дизайн — разбить изменения агрегатов на разные транзакции.

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

   2. Если разбиение через события приводит к появлению каскада событий, то можно просто разбить операцию на несколько транзакций.

4. Если я уверен, что операция имеет высокую связанность, а конкуренция за агрегат низкая (он меняется редко или только одним пользователем) — оставить всё как есть.

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

«Большие» тексты и массивы байт (картинки) я всегда выношу в отдельные агрегаты, даже когда это приводит к нарушениям принципов общей области жизни и изменения одного агрегата в одной транзакции. «Большой» — понятие относительное, и я выделяю атрибуты, если математическое ожидание их размера превышает ~4 килобайта.

«Действительно многие» связи я также всегда выношу в отдельные агрегаты вопреки
остальным принципам. «Действительно многие» — тоже понятие относительное, и я выношу связи, когда математическое ожидание количества связанных объектов превышает ~20 штук.

Для проверки всех остальных принципов у меня нет устоявшихся инструментария и эвристик и их нарушение я ищу «методом вдумчивого взгляда».

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

Частые ошибки проектирования агрегатов

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

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

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

1. удобство навигации — связь добавляется, чтобы была возможность добраться до объекта А, имея на руках объект Б.

2. отражение реальности — связь добавляется потому, что «в реальности» сущности связаны.

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

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

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

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

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

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

1. Усложняется задача тестирования трансформаций.

2. Снижается переиспользуемость трансформаций.

3. Усложняется задача понимания кода из-за смешения разных уровней абстракции в сервисе приложения.

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

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

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

1. Каждый пользователь по каждой паре может вести торги с использованием «грида» — по сути, набора значений параметров алгоритма торговли.

2. В каждый момент времени для каждого символа пользователя может быть активен только один из гридов символа.

3. Гриды уникально идентифицируются своим именем.

4. Для каждого грида хранится статистика по торгам с его участием (в примере — только доход).

5. Статистика может меняться только у активного грида.

6. Каждый пользователь может вести торги одновременно по нулю и более символов.

Так же есть ограничение на 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>) {
  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. Как и от изменения статистики по неактивному гриду.

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

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

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

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е или сценарным тестом.

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

FAQ

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

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

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

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

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

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

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

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

   2. Минусы: повышает сцепленность между клиентами и агрегатом.

2. Предоставлять API в том числе для получения информации только на уровне корня агрегата. В этом случае внутренние сущности вообще не попадают в публичное API агрегата.

   1. Плюсы: полностью скрывает устройство агрегата и минимизирует связанность между клиентами и агрегатом.

   2. Минусы: плохо масштабируется по количеству методов запроса информации.

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

   1. Плюсы: может быть использован в случае, когда нет возможности сделать объекты неизменяемыми.

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

4. Использовать «read-only» представления. Похож на третий подход, но вместо копий предполагается возвращать «read-only» представления изменяемых сущностей.

   1. Плюсы: нет необходимости в коде копирования объектов и снижение нагрузки на сборщика мусора.

   2. Минусы: требует описания дополнительных интерфейсов для представлений и не очень надёжен — никто не запретит клиенту привести объект к изменяемому типу или поменять его через механизм рефлексии.

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

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

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

1. Сборка DTO из агрегатов. Заключается в том, чтобы вытащить нужные агрегаты из репозиториев и собрать из них DTO.

   1. Плюсы — минимальная сцепленность модулей, минимум дополнительного кода

   2. Минусы — потенциальные проблемы с производительностью из-за нескольких запросов в БД и больше ручной работы по добавлению зависимостей на репозитории и чтению данных из них.

2. Сборка DPO из агрегатов. По сути то же, что и первый вариант, только клиенту выдаётся Data Payload Object (DPO), вместо DTO. DPO — это набор агрегатов, из которого клиент сам строит нужные ему структуры.

   1. Плюсы — минимальная сцепленность модулей, не нужен код для маппинга агрегатов в клиентские структуры.

   2. Минусы — клиенту будут возвращаться лишние данные, что может плохо сказаться на эффективности и безопасности системы.

3. Отдельные модели для записи и чтения. В дополнение к модели для записи (агрегаты), создаётся дополнительная денормализованная модель для чтения.

   1. Плюсы — эффективная работа с БД и создание DTO средствами ORM.

   2. Минусы — неявная сцепленность модуля генерации DTO с деталями реализации всех модулей агрегатов, в два раза больше кода для описания модели данных.

4. Сборка DTO в СУБД. Современные СУБД (PostgreSQL, в частности) имеют встроенные средства для формирования JSON и позволяют собрать финальную DTO непосредственно SQL-запросом.

   1. Плюсы — самая эффективная работа с БД.

   2. Минусы — завязка на диалект определённой СУБД, менее удобный инструментарий для работы с SQL-запросами (чем с кодом на Kotlin, например), примитивные средства переиспользования кода и создания абстракций в самом SQL.

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

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

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

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

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

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

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

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

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

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

1. Агрегат преимущественно изменяется одним пользователем — исключает проблемы с синхронизацией.

2. Агрегат остаётся ограниченным по размеру в байтах — исключает проблемы с производительностью.

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

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

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

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

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

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

1. если обеспечение согласованности изменений является ответственностью пользователя, инициировавшего выполнение операции — то модификации должны быть строго согласованы.

2. иначе — можно обойтись согласованностью в конечном итоге.

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

1. «Закрыть» этот неудобный инвариант и перейти к согласованности в конечном итоге.

2. Убрать из агрегата «лишние» сущности, которые были включены в него по причинам отличным от обеспечения инварианта.

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

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

Заключение

Агрегаты — действительно сложная тема:

Clustering Entities (5) and Value Objects (6) into an Aggregate with a carefully crafted consistency boundary may at first seem like quick work, but among all DDD tactical guidance, this pattern is one of the least well understood.

— Vaughn Vernon, Implementing Domain-Driven Design

и её невозможно полностью понять, прочитав один пост.

Но я постарался собрать в этом посте необходимый минимум информации для того, чтобы спроектировать первый агрегат.

Дальнейшее чтение по теме

• [idddd] An In-Depth Understanding of Aggregation in Domain-Driven Design

• [ddd] Domain-Driven Design: Tackling Complexity in the Heart of Software

• [dddmf] Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

• [dddd] Domain-Driven Design Distilled

• [pppofddd] Patterns, Principles, and Practises of Domain-Driven Design

• [iddd] Implementing Domain-Driven Design

Основные инструкции правильной установки наших агрегатов

Основные инструкции правильной установки агрегатов CoolPacket

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

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

• Все наши агрегаты перевозятся на грузовом автотранспорте, погрузка на который осуществляется с помощью мостового крана. Для предотвращения повреждений компрессоров при транспортировке или в ходе монтажа, агрегаты не должны быть наклонены, не должны укладываться на одно сторону или в перевернутом положении. Поэтому необходимо, чтобы при перемещении в ходе монтажа или при транспортировке агрегаты всегда находились в рабочем положении.
• Наши агрегаты сконструированы для поднимания с помощью штанг, вставленных в соответствующие отверстия в элементах несущей конструкции агрегата. Для предотвращения контакта подъёмных тросов и цепей с установкой и повреждения ее конструкции рекомендуется использовать крестовину или распорные штанги. Поэтому рекомендуется строго соблюдать инструкцию по подъёму оборудования, поставленную вместе с установкой, в которой находится более подробная дополнительная информация.
• Поверхность, на которую установка будет поставлена, должна быть ровной и с достаточной несущей способностью, чтобы выдержала нагрузки от агрегата (см. чертёж весовых нагрузок, поставленный вместе с установкой, и техническую записку).
• Для глушения передачи вибраций на конструкцию, на которую агрегат установлен, необходимо во всех опорных точках использовать гасители вибраций. У агрегатов, которые будут поставлены на землю, рекомендуется использовать резиновые гасители вибраций, а для установок, располагаемых на крыше, рекомендуются пружинные амортизаторы.
• Для обеспечения правильного движения потока воздуха и свободного доступа для проведения технического обслуживания вокруг оборудования должно быть оставлено достаточно свободного места – см. спецификацию в технической записке к каждой установке. В случае расположения двух агрегатов возле себя, причем змеевиками друг к другу, расстояния, указанные в технической записке, необходимо удвоить. 
• Внимание! Несоблюдение этого технического правила автоматически несет за собой потерю гарантии и выплывающего из нее права на бесплатный ремонт, несмотря на то, по какой причине возникла неисправность.
• Перед чисткой агрегата, должны быть прочищены все трубопроводы рабочего оборудования. Если для прочистки труб необходимо применить химические вещества, то в этом случае испаритель необходимо перекрыть и обойти для предотвращения возможного повреждения медных трубок.
• При наличии загрязнений и/или агрессивного конденсата воды перед конденсатором холодильного агрегата должен быть установлен промежуточный теплообменник «вода-вода».
• Выполнение вышеупомянутых инструкций по монтажу является необходимым условием для признания действия гарантии и выплывающих из нее обязательств.
• Объём воды. 
• Для правильной работы агрегата необходим определённый объём воды, который рассчитывается по следующим формулам:

 

P = производительность по холоду холодильного агрегата и по теплу теплового насоса в кВт.

_t = разность температур, заданная микропроцессором в °C.

V = полезный объём воды, выраженный в кубических метрах (м3).

 

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

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

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

 

Агрегаты »воздух-воздух»

1. Воздуховоды подсоединены на всасывание вытяжных вентиляторов, понижение загрузки которых должно быть в соответствии с проектными величинами установок.
2. Подсоединение этих воздуховодов к агрегатам должно осуществляться посредством антивибрационных вставок из непроницаемой ткани. Это имеет принципиальное значение для предотвращения передачи вибраций от агрегатов на воздуховоды.
3. Особое внимание надо уделять проектированию и монтажу всасывающего трубопровода и напорного воздуховода для змеевиков теплообменников так, чтобы не возникали препятствия, ограничивающие пропускную способность потока воздуха. Низкий расход воздуха, протекающего через змеевик теплообменника, становится причиной ненормальной работы агрегата и его окончательного выхода из строя. 
4. Эти трубопроводы должны быть максимально короткими и по возможности проложены по прямой трассе.
5. Защитные решетки, установленные на всасывании наружного воздуха, должны быть конструированы так, чтобы создавали минимальное сопротивление потоку воздуха.
6. Должны быть приняты все необходимые меры для предотвращения смешивания выбрасываемого и рекуперативного (возвратного) воздухa (кратковременное взаимное соединение контуров воздуховодов).
7. Воздух для теплообменника не должен всасываться вблизи источников тепла и/или загрязнений.
8. За решетками на выхлопах или на всасывании должны быть установлены сетки для предотвращения проникания птиц и мышей в воздуховоды вентиляционной системы.

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

1. Подсоединение этих воздуховодов к агрегатам должно осуществляться посредством антивибрационных вставок из непроницаемой ткани. Это имеет принципиальное значение для предотвращения передачи вибраций от агрегатов на воздуховоды.
2. Особое внимание надо уделять проектированию и монтажу всасывающего трубопровода и напорного воздуховода для змеевиков теплообменников так, чтобы не возникали препятствия, ограничивающие пропускную способность потока воздуха. Низкий расход воздуха, протекающего через змеевик теплообменника, становится причиной ненормальной работы агрегата и его окончательного выхода из строя. 
3. Эти трубопроводы должны быть максимально короткими и по возможности проложены по прямой трассе.
4. Защитные решетки, установленные на всасывании наружного воздуха, должны быть конструированы так, чтобы создавали минимальное сопротивление потоку воздуха.
5. Должны быть приняты все необходимые меры для предотвращения смешивания выбрасываемого и рекуперативного (возвратного) воздухa (кратковременное взаимное соединение контуров воздуховодов).
6. Воздух для теплообменника не должен всасываться вблизи источников тепла и/или загрязнений.
7. За решетками на выхлопах или на всасывании должны быть установлены сетки для предотвращения проникания птиц и мышей в воздуховоды вентиляционной системы.

 

Агрегаты »воздух-воздух» и кровельные агрегаты

• Все наружные и внутренние агрегаты (разделенная система охлаждения кондиционирования) оснащены сливными поддонами, расположенными под змеевиками теплообменников.
• Сливной трубопровод должен быть такого же диаметра (или больше), как и присоединительный патрубок агрегата, который, как правило, оснащен внутренней резьбой 1″, причём уклон трубопровода должен быть примерно 3 % в сторону потока жидкости.
• На трубопроводе должен быть установлен сифон, высота которого должна соответствовать высоте напора вентилятора, что не позволяет вентилятору создавать разрежение, которое препятствовало бы нормальному отведению конденсата.

 

Кровельные агрегаты

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

• Два манометра с соответствующей впускной и выходной шкалой.
• Две антивибрационные соединительные вставки, предотвращающие передачу вибраций от агрегата на водопровод и позволяющие производить независимое отключение агрегата.
• Отсекающий клапан (на входе в устройство)
• Калибровочный клапан (на входе в агрегат)
• Два термометра (на входе и выходе).
• Циркуляционный насос.
• Предохранительный клапан бака.
• Автоматический сливной клапан бака.
• Расширительный бак.
• Фильтр на вводе, расположенный как можно ближе к фланцу испарителя.
• Расходомер

Вышеупомянутые инструкции по монтажу для типовой серии RED LINE обуславливают признание действия гарантии; при несоблюдении этих инструкций действие гарантии и выплывающих из нее обязательств прекращается.

Инструкции, касающиеся антивибрационных соединительных элементов, устанавливаемых на трубопроводах, фильтра на входе в испаритель и расходомера обуславливают признание действия гарантии на к типовую серию BLUE LINE; при несоблюдении этих инструкций действие гарантии и выплывающих из нее обязательств прекращается.

 

• Разъемные компрессоры могут быть установлены на пружинных виброгасителях.
• В этом случае надо устранить фиксаторы (деревянные колодки), блокирующие основание компрессора в соответствии с инструкциями на щитке, закрепленном на корпусе компрессора.
• Агрегат необходимо установить на расстоянии минимально 6 м от всех отражающих звук поверхностей, что предотвратит увеличение уровня шума примерно на 3 дБ (A) от всех отражающих звук поверхностей.
• Агрегат установить так, чтобы к местам чувствительным к шуму он был повернут боковыми стенками, излучающими минимальный уровень шума. В некоторых случаях с помощью простого приспособления можно избежать необходимости использования оборудования для подавления шума, как например противошумовые щиты.

Если агрегат установлен на крыше:

• Помещения, расположенные под ним, необходимо изолировать кровлей с высокой степенью звуконепроницаемости.
• Соответствующим способом должна быть усилена опорная конструкция, причем так, чтобы вибрации не переносились во внутрь здания.
• Установите агрегат на пружинные амортизаторы вибраций.
• Опорную конструкцию агрегата отделить от несущей конструкции здания, используя для этого соответствующие упругие соединительные элементы.
• Гидравлические трубы и электрические кабели агрегата необходимо отделить при помощи гибких соединений. Если агрегат установлен на двутавровых траверсах, высотой более 20 см, то по периметру между агрегатом и кровлей необходимо уложить подходящие панели. 
• Это позволит значительно снизить эффект «резонирующего шкафа», который в противном случае мог бы способствовать повышению уровня шума в просторе под агрегатом на 15 дБ (А).

 

ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ

 

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

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

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

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

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

Это даст возможность своевременного выявления эксплуатационных недостатков, и свести к минимуму риск возникновения серьёзных неполадок.

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

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

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

 

„Отопительные агрегаты, которые отапливают помещения в зимнее время с полным или частичным использованием машинного оборудования и систем не на базе теплогенераторов, установок и систем с тепловыми насосами (…), должны вестись «Эксплуатационный журнал системы», выданный поставщиком рабочего оборудования или лицом, ответственным за эксплуатацию и техобслуживание существующего рабочего оборудование. Этот журнал должен содержать не только описание самого рабочего оборудования, но также и перечень элементов, подлегающих контролю, пределы допустимости этих элементов согласно действующему законодательству, а также интервалы контрольных осмотров (…).»

 

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

 

• Каждый месяц должна производиться подтяжка всех электрических соединений, особенно это касается подключений контакторов и ввода электроэнергии.
• Регулярно контролировать и чистить на приточном водопроводе испарителя в зависимости от вида источника воды и от срока службы водопроводной системы.
• Минимально раз в год проводить визуальный осмотр состояния напорного оборудований, особенно необходимо контролировать, если на поверхности не появляются признаки коррозии, если не коррозируются другие детали и, если не проявляются другие видимые дефекты.
• Если оксидация и коррозия не будут своевременно обнаружены и надлежащим способом остановлены, то может произойти ослабление стен с последующим снижением их механической прочности.
• Минимально два раза в год проводить контроль контура охлаждения, при этом необходимо отстранить любые обнаруженные утечки ХФУ (фреона).
• Минимально два раза в год, всегда перед началом летнего и зимнего сезона, прочистить змеевики теплообменников раствором специального препарата для удаления накипи и осадков, снижающих эффективность теплообмена.
• У агрегатов типа «вода-вода» один раз за полгода (6 месяцев) контролировать эффективность работы и чистоту теплообменника и конденсатора. Испаритель необходимо прочищать с использованием раствора специального препарата от удаления осаждений, запрещается использовать химические чистящие средства. Трубки конденсатора можно протирать тряпкой.
• Каждый месяц определять потребление (расход) электроэнергии у компрессоров и электродвигателей вентиляторов, измеренное потребление эл. энергии сравнить с параметрами, указанными на заводском щитке, определить все величины, которые не соответствуют данным, уведенным на заводском щитке.
• Контролировать загруженность хладагента, что необходимо производить измерением перегрева или переохлаждения. При помощи оборудования по обнаружению утечек проверить, если в оборудовании нет утечек фреона.
• Один раз за 6 месяцев проверить состояние механических компонентов с подвижными частями (вентиляторы, насосы).
• Один раз за 6 месяцев делать лабораторный анализ кислотности масла в контуре охлаждения. Масло и соответствующие фильтры всегда должны быть заменены после 5000 отработанных часов или через каждых 2 года.
• После каждых 10000 отработанных часов разъемного компрессора должен производиться контроль всех механических и электрических частей самого компрессора.
• Каждый год производить контроль фильтров в контуре охлаждения и замену фильтрующих вкладышей.

 

Агрегаты »воздух/воздух», кровельные агрегаты или агрегаты с радиальными вентиляторами

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

Рекомендации по первому запуску

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

Контрактные гарантии будут подтверждены только после завершения этих работ.

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

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

1. Произвести проверку исполнения и контроль правильности электрических и гидравлических подсоединений и вводов.
2. Подключить агрегат к вводу электросети не менее чем 24 часа до прибытия техников специализированного центра Сервисной службы.
3. Правильно заполнить гидравлическую систему и удалить воздух из заполненного гидравлического трубопровода.
4. Докончить все необходимые работы, напр., монтаж трубопровода для отведения конденсата и т.п.
5. Проверить направление вращения насосов.
6. Проверить и отстранить все перемычки, которые могут быть применены на защитном и аварийном рабочем оборудовании.
7. Вычистить фильтр на вводе подающего водопровода в агрегат.
8. Убедитесь в том, что в наличии имеется хотя бы 75 % общей тепловой нагрузки.
9. Проверьте, если ввод электрической энергии является достаточной и соответствует агрегату (агрегатам) а другому рабочему оборудованию.
10. Проверить исправность затяжки электрических соединений.
11. Предоставить техникам лицензированного центра Сервисной службы всю документацию, поставленную в комплекте с агрегатом.

 

Заполнители

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

Для получения качественной бетонной смеси заполнители должны быть чистыми, твердыми, прочными, без абсорбированных химикатов или покрытий из глины и других мелких материалов, которые могут вызвать разрушение бетона. Заполнители, составляющие от 60 до 75 процентов от общего объема бетона, делятся на две отдельные категории — мелкие и крупные. Мелкие заполнители обычно состоят из природного песка или щебня, причем большинство частиц проходят через сито 3/8 дюйма. К крупным агрегатам относятся любые частицы крупнее 0,19дюйма, но обычно имеют диаметр от 3/8 до 1,5 дюйма. Гравий составляет большую часть крупного заполнителя, используемого в бетоне, а щебень составляет большую часть остатка.

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

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

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

• классификация
• долговечность
• форма частиц и текстура поверхности
• сопротивление истиранию и скольжению
• удельный вес и пустоты
• поглощение и поверхностная влажность

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

Форма частиц и текстура поверхности влияют на свойства свежезамешанного бетона больше, чем на свойства затвердевшего бетона. Шероховатые, угловатые и удлиненные частицы требуют больше воды для производства бетона, пригодного для обработки, чем гладкие, округлые компактные заполнители. Следовательно, содержание цемента также должно быть увеличено для поддержания водоцементного отношения. Как правило, плоских и удлиненных частиц избегают или ограничивают примерно 15 вес.% от общего заполнителя. Удельный вес измеряет объем, который гранулированный заполнитель и пустоты между ними будут занимать в бетоне.

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

 

Что такое агрегаты и как они используются? | CEMEX USA — CEMEX USA

Что такое агрегаты и как они используются?

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

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

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

Важность заполнителей для бетона
 

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

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

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

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

 

Типы заполнителей для бетона

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

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

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

• Щебень — Эти продукты получают путем извлечения горных пород и их дробления до желаемого размера и текстуры. Источники горных пород могут быть магматическими, осадочными или метаморфическими.
• Песок — песок встречается в природе. Это тонкий состав каменного материала и минеральных частиц, и его состав варьируется в зависимости от источника. Его можно использовать для строительства дорог или для изготовления бетона. Различные типы песка включают: песок 4 блока; песок 4 порционный; песок 5; песок 4; и песок 5 промыт.
• Гравий — Залежи гравия образуются в результате естественного процесса увлажнения и эрозии.