LS2019: Use Case Names a Type of Another Use Case

Reference#

What the Rule Enforces#

LS2019 enforces Keep Use Case Folders Isolated (litespec/backend/dotnet/architecture#keep-use-case-folders-isolated). It runs in every layer except Test. Its category is LiteSpec.Layers. Severity and enablement follow the Analyzers overview.

What the Rule Reports#

The rule reports a name in a use case or reaction folder under UseCases/ that resolves to a type declared in another such folder. The diagnostic sits on the name, and its message names the type and the folder that owns it.

Failing Example#

namespace Claimwick.Spending.Expenses.UseCases.SubmitExpense;

internal sealed class SubmitExpenseCommandHandler
{
    public void Handle() => ApproveExpensePolicy.ForExpense();
}

with ApproveExpensePolicy declared in the ApproveExpense/ folder.

Passing Example#

namespace Claimwick.Spending.Expenses.UseCases.SubmitExpense;

internal sealed class SubmitExpenseCommandHandler(IExpensePolicy policy)
{
}

with IExpensePolicy declared in the Expenses/Application/ folder.

How to Fix#

Move the shared type to the aggregate, module, or shared kernel layer folder that holds every consumer naming it. A type two use cases name belongs beside their aggregate, not inside either slice.

Notes#

What the Rule Ignores#

The rule does not report a name in a Test file or in a file the layer rules cannot place. It does not report a type in the same folder or in a layer folder, a name that resolves to no project source file, or a use case message or result: a type whose outermost type ends in Command, Query, CommandResult or QueryResult, which a reaction or use case that runs that use case sends and reads.