Data Activities defines the base classes that help us implement our architectural pattern, centered around business activities. All the concepts developed in this context owe a lot to the vision and the ideas of Yves Darmaillac.

We define an activity as a part of a business process. All the business process parts that are involved in a business application define this application activities. An activity is a , comprising two kinds of states :

  • treatment states : those require no external data (think user interaction). For instance, a treatment state can perform an action on our domain model (create a new reservation), or directly on the data (calculate booking fees). All a treatment state needs to perform its action is data.
  • question states : those do require external data. For instance, a question state can ask for data for a domain model instance (fill reservation details), or it can ask for a specific domain model instance (pick up your seat). Usually, a question is answered via user interaction (but not necessarily, like in the case of unit tests where answers can be automated).

The golden rule here is to make sure that all the application behavior is defined in terms of activities. Treatments are by definition self-sufficient and generic. Questions define abstractions that have to be implemented by the HMI layer. In effect, such abstractions can be implemented by all kinds of presentation technologies (console applications, Windows Forms, ASP .NET, WPF...) with no impact on the business logic.

BasicsThe fundamental interfaces defined in this library are :

  • IActivityState is an interface implemented by an activity state, and treatment states in particular. IQuestionActivityState is a specialization that is implemented by a question state.
  • IActivityData is implemented by an activity data holder type : it holds the data that is manipulated by a specific activity.
  • IActivityParameters is implemented by an activity parameters holder type. An activity parameter could be seen as an immutable activity data.
  • IActivityController is implemented by an activity controller. Such a class is essential to the activity execution : it initiates the activity, terminates it and controls all the state transitions in between.

All the states must be validated before transition : this is achieved via the integration of Data Rules. The library defines base implementations for all these interfaces, and helpful classes to implement questions in specific presentation technologies (so far Windows Forms and ASP .NET).

Activities are at the core of our architecture : they manipulate data and act as a separation of concerns between the business logic and the presentation. In the future, we will be able to design our activities via our own DSL (SAML), and have base implementations (and best practices) for questions in other technologies such as WPF or ASP .NET AJAX.

I would like to finish with an analogy that might confuse some readers, but hopefully enlighten others : imageI like to think of a business activity as a RNA translation process, which is part of the protein biosynthesis. The elements involved in this process are :

  • a mRNA template. It holds the code for a specific protein. This code has a start and an end, and has to be followed in order. This is our finite state machine, each codon being seen as a state.
  • a ribosome. This is the protein "factory". It "reads" the codons one by one and performs an action on each of them : add the corresponding amino acid to the chain that will become our protein. This is our activity controller.
  • the protein. This is the result of the entire process. This could be seen as our data.