Etwas abstrakt: In einem Workfluss definierst Du Zustände der Arbeit, und Übergänge zwischen diesen Zuständen. Dazu dann noch Regeln, unter welchen Umständen einer dieser Zustandsübergänge überhaupt möglich ist. Klassiker Bugtracker: Ticket neu. Übergänge zu Abgelehnt und Zugewiesen. Beide Übergänge dürfen nur von einem Teamleiter ausgelöst werden, bei zugewiesen muss ein Entwickler ausgewählt werden, bei Abgelehnt eine Begründung eingegeben.
Eine ordentliche Workflow-Engine (z.B. die aus .NET 4.0, NICHT die aus den früheren Versionen) erlaubt es Dir, diese Zustände und Übergänge leicht zu definieren und die Ausführung zu überwachen. Die Workflow foundation in .NET bietet Dir darüber hinaus auch die Speicherung der Workflow-Zustände in einer Art die es erlaubt, verteilte Workflows zu modellieren (d.h. der Statusübergang kann in einer anderen Software auf einem anderen System passieren, was z.B. bei Bestellsystemen der Fall sein kann). Ausserdem laufen dort die Statusübergänge meist transaktionell durch. Und genau an der Stelle fangen die Systeme dann auch an, Dir als Entwickler die Arbeit abzunehmen. Einen Workflow mit ein paar Enums bekommt man relativ easy hin, aber wenn es dann um die konsequente Überwachung, Zusicherung der Zustände und die Persistenz geht fängt es an, viel Code zu werden. Und diesen Code nehmen einem die Systeme dann irgendwann ab.
Danke, jetzt habe ich's verstanden!
