Рассмотрение конструкции шаблон домен


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

Случай использования:

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

 public interface IDomainService<T, Y, X> 
    where Y : Resources.IBaseRequest
    where T : Resources.IBaseResponse
    where X : Resources.IBaseRequirements
{

    T Submit(Y request);

    X Requirements(Y request);
}

В коде выше, определение IBaseRequest, IBaseResponse и IBaseRequirements менее важны, так как они в основном имеют общие свойства, но, как правило, важно определить, будет ли объект запроса, ответ или требование.

Пример запроса, ответ и требование на службу корректировки.

 public interface IAdjustmentRequest : IBaseRequest
{
    AdjustmentType AdjustmentType { get; set; }

    decimal AdjustmentQty { get; set; }

    string TrackingEntityBarcode { get; set; }
}

public interface IAdjustmentRequirements : IBaseRequirements
{
    DomainEntities.TrackingEntity TrackingEntity { get; set; }
}

public interface IAdjustmentResponse : IBaseResponse
{
    DomainEntities.TrackingEntity TrackingEntity { get; set; }
}

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

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

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

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

  public class AdjustmentService : DomainBaseService<IAdjustmentResponse, IAdjustmentRequest, IAdjustmentRequirements>
{
    protected internal override IAdjustmentRequirements TransactionRequirements(IAdjustmentRequest request)
    {
        Resources.AdjustmentRequirements response = new Resources.AdjustmentRequirements(request);
        try
        {
            //user
            base.RequestUser(request, ref response);

            //inventory
            response.TrackingEntity = this.ValidateTrackingEntity(request.TrackingEntityBarcode);

            //validate qty
            if (request.AdjustmentType == Interface.AdjustmentType.QtyDecrease)
                if (request.AdjustmentQty > response.TrackingEntity.Qty)
                    throw new Exception(ExceptionInsufficientOnhand);

            response.Valid = true;
            return response;
        }
        catch (Exception ex)
        {
            response.ErrorMessages = ex.Message;
            response.Valid = false;
            return response;
        }
    }
    protected internal override IAdjustmentResponse CommitTransaction(IAdjustmentRequirements request)
    {
        try
        {
            Resources.AdjustmentResponse response = new Resources.AdjustmentResponse()
            {
                Transactions = new List<Transaction>(),
                User = request.User
            };

            switch (request.AdjustmentType)
            {
                case Granite.DomainModel.Interface.AdjustmentType.QtyIncrease:
                    request.TrackingEntity.Qty += request.AdjustmentQty;
                    break;
                case Granite.DomainModel.Interface.AdjustmentType.QtyDecrease:
                    request.TrackingEntity.Qty -= request.AdjustmentQty;
                    break;
            }

            Transaction transaction = this.BuildProcessTransaction(request, request.TrackingEntity);

            response.Transactions.Add(transaction);
            response.TrackingEntity = request.TrackingEntity;

            Repository.Session.SaveOrUpdate(transaction);
            Repository.Session.SaveOrUpdate(request.TrackingEntity);

            response.ResponseMessage = string.Format("Adjusted {0} by {1}", request.TrackingEntityBarcode, request.AdjustmentQty);
            return response;
        }
        catch (Exception ex)
        {
            throw new Exception(ex.Message);
        }
    }



}

Эти два метода четко разделил с точки зрения ответственности; один делает все проверки и, если принят другой не упорство.

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

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



Комментарии
1 ответ

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

try
{
//user
base.RequestUser(request, ref response);

//inventory
response.TrackingEntity = this.ValidateTrackingEntity(request.TrackingEntityBarcode);

//validate qty
if (request.AdjustmentType == Interface.AdjustmentType.QtyDecrease)
if (request.AdjustmentQty > response.TrackingEntity.Qty)
throw new Exception(ExceptionInsufficientOnhand);

response.Valid = true;
return response;
}
catch (Exception ex)
{
response.ErrorMessages = ex.Message;
response.Valid = false;
return response;
}


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

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


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

    Это позволило бы две вещи; альтернативные реализации, и блок
    Тестирование с небольшой реализацией интерфейса.


1
ответ дан 19 марта 2018 в 11:03 Источник Поделиться