Служба управления доменом-приводом

Question

Я нахожусь в поиске лучшего (или лучшего) подхода при написании доменных служб на основе доменного дизайна. Вот псевдо-код

public class CustomerAccount 
{ 
    public string AccountNumber {get; set;} 
    public string CustomerName {get; set;} 
    public string PhoneNumber {get; set;} 
    public string HomeAddress {get; set;} 
} 

// Domain Service Class 
public class AccountService 
{ 
    public virtual void RefreshAccount(CustomerAccount acct) 
    { 
     // Some code here to refresh the class from cache... 
     cache.refresh(acct) 
    } 
} 

public static class Cache 
{ 
    public static refresh(CustomerAccount acct) 
    { 
     // refreshing class here. 
    } 
} 

У меня есть вопрос, я должен иметь RefreshAccount() внутри AccountService и вызовите на это таким образом? Или просто вызовите класс кеша напрямую? В любом случае, отлично работает, но мой вопрос касается, с точки зрения дизайна, особенно DDD, какой путь является лучшим и почему?

Спасибо заранее!

Answer 1

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

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

В целом:

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

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

Answer 2

DDD и Test Driven Development обычно идут рука об руку, поэтому с точки зрения TDD вы захотите сохранить ее так, как она есть, и не вызывайте метод статического обновления напрямую; в противном случае будет очень сложно правильно выполнить тестирование.