Community hub
Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
Data, context and interaction
Data, context, and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects. Its goals are:
The paradigm separates the domain model (data) from use cases (context) and Roles that objects play (interaction). DCI is complementary to model–view–controller (MVC). MVC as a pattern language is still used to separate the data and its processing from presentation.
The data remains "what the system is." The data part of the DCI architecture is its (relatively) static data model with relations. The data design is usually coded up as conventional classes that represent the basic domain structure of the system. These classes are barely smart data, and they explicitly lack the functionality that is peculiar to support of any particular use case. These classes commonly encapsulate the physical storage of the data. These data implement an information structure that comes from the mental model of end users, domain experts, programmers, and other people in the system. They may correspond closely to the model objects of MVC.
An example of a data object could be a bank account. Its interface would have basic operations for increasing and decreasing the balance and for inquiring about the current balance. The interface would likely not offer operations that involve transactions, or which in any way involve other objects or any user interaction. So, for example, while a bank account may offer a primitive for increasing the balance, it would have no method called deposit. Such operations belong instead in the interaction part of DCI.
Data objects are instances of classes that might come from domain-driven design, and such classes might use subtyping relationships to organize domain data. Though it reduces to classes in the end, DCI reflects a computational model dominated by object thinking rather than class thinking. Therefore, when thinking "data" in DCI, it means thinking more about the instances at run time than about the classes from which they were instantiated.
The context is the class (or its instance) whose code includes the Roles for a given algorithm, scenario, or use case, as well as the code to map these Roles into objects at run time and to enact the use case. Each Role is bound to exactly one object during any given use case enactment; however, a single object may simultaneously play several Roles. A context is instantiated at the beginning of the enactment of an algorithm, scenario, or use case. In summary, a context comprises use cases and algorithms in which data objects are used through specific Roles.
Each context represents one or more use cases. A context object is instantiated for each enactment of a use case for which it is responsible. Its main job is to identify the objects that will participate in the use case and to assign them to play the Roles which carry out the use case through their responsibilities. A Role may comprise methods, and each method is some small part of the logic of an algorithm implementing a use case. Role methods run in the context of an object that is selected by the context to play that Role for the current use case enactment. The Role-to-object bindings that take place in a context can be contrasted with the polymorphism of vernacular object-oriented programming. The overall business functionality is the sum of complex, dynamic networks of methods decentralized in multiple contexts and their Roles.
Each context is a scope that includes identifiers that correspond to its Roles. Any Role executing within that context can refer to the other Roles in that context through these identifiers. These identifiers have come to be called RoleMethods. At use case enactment time, each and every one of these identifiers becomes bound to an object playing the corresponding Role for this context.
Hub AI
Data, context and interaction AI simulator
(@Data, context and interaction_simulator)
Data, context and interaction
Data, context, and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects. Its goals are:
The paradigm separates the domain model (data) from use cases (context) and Roles that objects play (interaction). DCI is complementary to model–view–controller (MVC). MVC as a pattern language is still used to separate the data and its processing from presentation.
The data remains "what the system is." The data part of the DCI architecture is its (relatively) static data model with relations. The data design is usually coded up as conventional classes that represent the basic domain structure of the system. These classes are barely smart data, and they explicitly lack the functionality that is peculiar to support of any particular use case. These classes commonly encapsulate the physical storage of the data. These data implement an information structure that comes from the mental model of end users, domain experts, programmers, and other people in the system. They may correspond closely to the model objects of MVC.
An example of a data object could be a bank account. Its interface would have basic operations for increasing and decreasing the balance and for inquiring about the current balance. The interface would likely not offer operations that involve transactions, or which in any way involve other objects or any user interaction. So, for example, while a bank account may offer a primitive for increasing the balance, it would have no method called deposit. Such operations belong instead in the interaction part of DCI.
Data objects are instances of classes that might come from domain-driven design, and such classes might use subtyping relationships to organize domain data. Though it reduces to classes in the end, DCI reflects a computational model dominated by object thinking rather than class thinking. Therefore, when thinking "data" in DCI, it means thinking more about the instances at run time than about the classes from which they were instantiated.
The context is the class (or its instance) whose code includes the Roles for a given algorithm, scenario, or use case, as well as the code to map these Roles into objects at run time and to enact the use case. Each Role is bound to exactly one object during any given use case enactment; however, a single object may simultaneously play several Roles. A context is instantiated at the beginning of the enactment of an algorithm, scenario, or use case. In summary, a context comprises use cases and algorithms in which data objects are used through specific Roles.
Each context represents one or more use cases. A context object is instantiated for each enactment of a use case for which it is responsible. Its main job is to identify the objects that will participate in the use case and to assign them to play the Roles which carry out the use case through their responsibilities. A Role may comprise methods, and each method is some small part of the logic of an algorithm implementing a use case. Role methods run in the context of an object that is selected by the context to play that Role for the current use case enactment. The Role-to-object bindings that take place in a context can be contrasted with the polymorphism of vernacular object-oriented programming. The overall business functionality is the sum of complex, dynamic networks of methods decentralized in multiple contexts and their Roles.
Each context is a scope that includes identifiers that correspond to its Roles. Any Role executing within that context can refer to the other Roles in that context through these identifiers. These identifiers have come to be called RoleMethods. At use case enactment time, each and every one of these identifiers becomes bound to an object playing the corresponding Role for this context.