Рефакторинг доменной логики, что репозитории доступов в унаследованной системе

Ответ Фредерика Гейзеля хороший, хотя, возможно, немного краткий. Чтобы уточнить: в вашем случае вы можете начать с определения интерфейса для вашей спецификации (простите мой синтаксис C #):

public interface ICarSpecification
{
    bool IsSatisfiedBy(CarComponentType carComponentType);
}

Затем вы можете создать внедрение ICarSpecification, которое использует ваш репозиторий. Примерно так:

public class CanDiscontinueSpecification : ICarSpecification
{
    private readonly CarRepository carRepository;

    public CanDiscontinueSpecification(CarRepository carRepository)
    {
         this.carRepository = carRepository;
    }

    public bool IsSatisfiedBy(CarComponentType carComponentType)
    {
        return this.carRepository.GetCarsWithComponent(carComponentType).Any();
    }
}

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

public class CarComponentType
{
    private readonly ICarSpecification discontinueSpec;

    public CarComponentType(ICarSpecification discontinueSpec)
    {
        this.discontinueSpec = discontinueSpec;
    }

    public bool CanBeDiscontinued()
    {
        return this.discontinueSpec.IsSatisfiedBy(this);
    }
}

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

public bool CanBeDiscontinued(ICarSpecification spec)
{
    return spec.IsSatisfiedBy(this);
}

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

Звучит как хороший кандидат для шаблона спецификации

Я не думаю, что «можно ли это прекратить» относится ни к одному из этих классов. Кто отвечает за определение возможности снятия с производства детали? Ни автомобиль, ни компонент автомобиля. Я думаю, что вы были на правильном пути, реализовав свой первоначальный метод в сервисе. Возможно, вам нужна служба CarInventoryManagementService, отвечающая за ответы на вопросы об элементах инвентаризации автомобилей, например:

carsUsingComponent( CarComponent comp )
canComponentBeDiscontinued( CarComponent comp )
etc

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

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

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

Кроме того, ИМХО, Я думаю, что ваши исходные фрагменты кода проще, чем решения, предложенные в других ответах (без обид, Марк и Фредерик, просто наблюдение :-) и что более сложное решение на самом деле не приносит никаких преимуществ - я имею в виду, что функциональность такая же в обоих случаях, но в последнем используется больше движущихся частей .

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

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

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

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

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