Befolgen Sie die Domänen-gesteuerten Prinzipien, < /p>
Nehmen wir an, wir bauen B2B-Auftragsmanagementsystem auf. Eine der Anforderungen ist, dass wir für jeden Kunden-/Bestell-/Bestellelement Personen zuweisen können, die den Auftragsfluss verwalten. In diesem Fall ist BWM der Kunde, die Bestellung enthält zwei Elemente: Lager und Befestigungselemente. Elon wurde dem Lagerbestellelement zugewiesen, damit er diesen Artikel nur
verwalten kann. Zum Beispiel kann er den Angebotspreis berechnen.
Code: Select all
public class Order
{
public CustomerId CustomerId { get; }
private List _items = [];
...
public ChangeOrderHeader() // Only Mark can do that
{
...
}
}
< /code>
public class OrderItem
{
public OrderId OrderId { get; }
...
public void PrepareOffer() // Available for Mark. Also for Elon if this is the bearing order item
{
...
}
}
< /code>
Die Frage: < /strong> Wie man die Berechtigungsvalidierung in diesem Fall verwaltet?public void PrepareOffer(User user)
{
EnsurePermissions(user); // Validation is in method, it also could be a policy
...
}
Das Problem besteht darin, dass Sie Benutzerinformationen/Richtlinien an jede Methode innerhalb eines Aggregats übergeben müssen. Auch nach meinem Verständnis sollte sich die Domäne für worden/wie und nicht um Who .public class Repository(IUserAccessor userAccessor)
{
public Task Save(Order order)
{
var user = userAccessor.GetCurrentUser();
if(order.WasModified())
{
EnsureOrderPermissions(order, user);
}
...
}
}
< /code>
Dieser Ansatz erzeugt keinen Code-Overhead, verschiebt die Geschäftslogik in die Infrastrukturschicht.public OrderService(IUserAccessor userAccessor)
{
public void PrepareOffer(Order order, OrderLineId orderLineId)
{
var user = userAccessor.GetCurrentUser();
EnsureOrderLinePermissions(orderLineId, user);
order.PrepareOrder(orderLineId);
}
}
< /code>
In diesem Fall haben wir mehr Code als im zweiten Ansatz, aber es erscheint logisch, die Berechtigungen in der Anwendungsschicht zu überprüfen.>
Mobile version