Many systems use the Layered approach to architecture, and it's likely that a ColdFrame-based system will do the same. In any case, there has to be support for interactions between different Domains (subject matters).
To avoid awkward dependencies, both at the design level and in the translated code, ColdFrame supports callbacks. Another name for this concept is the Observer pattern.
With callbacks, the lower-level domain provides a facility so that higher-level domains can register to be informed when a particular event occurs; when it does occur, the lower-level domain calls the callbacks, which notifies the registered higher-level domains (clients) without needing to know anything about them.
A domain can deregister from a callback, though it would be more normal to connect at initialization and stay connected.
In the lower-level domain, create a type corresponding to the event that clients need notifying about.
Mark it as a callback type by applying the «callback» stereotype.
If the data you want to transmit is a basic type (such as Boolean), you'll still need to create a domain type to apply «callback» to. This could be via a renaming.
First, import the callback type from the server domain (the stereotype «imported» and the tag {imported=Server}).
In an appropriate class, create an operation taking a single (in) parameter of the imported callback type, to act as the receiver.
ColdFrame provides automatic registration for such an operation with the server if you apply the stereotype «callback»; in that case the operation will be treated as a class operation. If you don't want this (that is, you'll register with the server callback "by hand"), you must model the operation as a class operation (by checking ownerScope).
For a «callback» type CB, ColdFrame generates an instantiation:
package Domain.CB_Callback is new ColdFrame.Callbacks (T => Domain.CB);
For a «callback» operation, ColdFrame generates the code necessary to move the callback message from the server domain's context to the client domain's context, using implicit class events. When the callback operation is invoked, it is in the client domain's context and can use synchronous event processing as appropriate.
Here's an example of mixing callbacks and events.
If all you want to say is that something has happened, mark your «callback» datatype «null» . ColdFrame generates a null record declaration. To create an instance of a null record (to call the callbacks with), say (null record).
Don't bother to deregister for callbacks during AUnit test teardown; ColdFrame automatically does this for you.