Проектирование и рефакторинг *

Первые реализации

1. Как помечать потребителей, которым мы уже отправили это письмо?
2. Как максимально быстро обработать всех потребителей и при этом не тормозить работу сайтов (которые обращаются к тем же записям в БД)?

1. Отправка рассылок идет из windows-сервиса, который периодически проверяет не появилось ли новых потребителей, подходящих под условия.
2. В сервисе первым шагом делается один запрос к БД с уровнем изоляции Read Uncommitted. Этот запрос вытаскивает Id всех потребителей, которым надо отправить письмо. Из-за низкого уровня изоляции такой запрос не накладывает блокировок на записи в БД и, как следствие, крайне слабо влияет на работу сайта. Однако он не гарантирует чистоту данных и их надо повторно проверить с более высоким уровнем изоляции.
3. После того, как мы вытащили Id потребителей, для каждого потребителя мы выполняем отдельную транзакцию с уровнем изоляции Serializable. В этой транзакции мы заново проверяем подходит ли потребитель под условия и если да, отправляем ему письмо и выдаем действие-маркер. Так как мы обрабатываем каждого потребителя в отдельной транзакции, блокировки накладываются только на данные одного потребителя и на работу остальных потребителей не влияют. Так как такая транзакция очень короткая, у потребителя, которому отправляют письмо, также не будет особых проблем, если он в это время ходит по сайту. Уровень изоляции транзакции должен быть именно Serializable, чтобы ненароком не отправить одно письмо дважды, или не отправить письмо тому потребителю, который внезапно перестал подходить под условия. Хотя, если мы гарантируем, что отправка одной и той же рассылки может идти только из одного потока и с одного сервера, а также забьем на небольшую вероятность того, что одному потребителю могут отправится две рассылки с взаимоисключающими условиями, то можно использовать и Read Committed транзакцию.

• шаблон действия-маркера (раньше мы называли шаблон типом действия: думаю, для разработчиков это более понятный термин), которое выдается при отправке письма
• метод, отправляющий письмо
• метод, выполняющий дополнительные действия (например, вместе с отправкой поздравления с днем рожденья, мы можем выдавать потребителю баллы на счет)
• метод, который формирует Expression<Func<Customer, bool>>, проверяющий, что потребитель подходит под условие

Замена наследования композицией

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

Add(new Trigger(“Приглашение на сайт для пришедших через канал one-to-one”)
{
	MarkerActionTemplateSystemName = “InvitationMarker”,
	TriggerAction = new TriggerActionCombination(
		new GeneratePasswordForCustomerTriggerAction(),
		new SendEmailTriggerAction(“InvitationMailing”)),
	TriggerCondition = new AndTriggerConditionSet(
		new CustomerHasSubscripionCondition(),
		new CustomerHasEmailTriggerCondition(),
		new CustomerHadFirstActionOverChannelCondition(“OneToOne”)),
});

public interface ITriggerAction
{
	void Execute(
		ModelContext modelContext, // класс для работы с БД 
		Customer customer);
}

public class TriggerCondition
{
	private readonly Func<ModelContext, Expression<Func<Customer, bool>>> triggerExpressionBuilder;

	public TriggerCondition(Func<ModelContext, Expression<Func<Customer, bool>>> triggerExpressionBuilder)
	{
		if (triggerExpressionBuilder == null)
			throw new ArgumentNullException("triggerExpressionBuilder");

		this.triggerExpressionBuilder = triggerExpressionBuilder;
	}

	public Expression<Func<Customer, bool>> GetExpression(ModelContext modelContext)
	{
		return triggerExpressionBuilder(modelContext, brand);
	}

	// Используется в Read Uncommitted транзакции для получения спиcка Id потребителей, подходящих под условие
	public IQueryable<Customer> ChooseCustomers(ModelContext modelContext, IQueryable<Customer> customers)
	{
		if (modelContext == null)
			throw new ArgumentNullException("modelContext");
		if (customers == null)
			throw new ArgumentNullException("customers");

		var expression = GetExpression(modelContext);
		return customers.Where(expression).ExpandExpressions();
	}

	// Используется в Serializable транзакции, для проверки, что потребитель все еще подходит под условие
	public bool ShouldTrigger(ModelContext modelContext, Customer customer)
	{
		if (modelContext == null)
			throw new ArgumentNullException("modelContext");
		if (customer == null)
			throw new ArgumentNullException("customer");

		var expression = GetExpression(modelContext);
		// Можно бы было просто вызывать expression.Evaluate(customer),
		// но тогда для сложных условий выполнилось бы несколько запросов в БД вместо одного
		return modelContext.Repositories.Get<CustomerRepository>().Items
			.Where(aCustomer => aCustomer == customer)
			.Where(aCustomer => expression.Evaluate(aCustomer))
			.ExpandExpressions()
			.Any();
	}
}

Все, надоело, сами заводите свои триггеры

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

Нужно больше Expression’ов

public sealed override Expression<Func<CustomerAction, bool>> GetIsMarkerExpression(ModelContext modelContext)
{
	return action => action.ActionTemplateId == ActionTemplateId;
}

public override Expression<Func<CustomerAction, bool>> GetIsMarkerExpression(ModelContext modelContext)
{
	IQueryable