Hi Rickard, I probably did something wrong, but my structure (passive) currently links to interactions (active).
One 'contract' is made of 'terms' (passive). Some terms are 'billable' (active behavior). When I choose to bill a client, I collect all the 'billable' terms into another passive structure, let's call it an invoice template. This invoice template points to a list of 'billable' terms of a couple of contracts. So my passive structure points to a list of behaviors, and I plan to add other 'billables' later, and they may not be terms of a contract (like exchange rates commissions). Is this a complete nonsense ? How should I handle this polymorphism ? phil On Wed, Jan 6, 2010 at 2:27 PM, Rickard Öberg <[email protected]> wrote: > Hey guys, > > We ran into some serious code tangle issues in StreamFlow with regard to our > entity code, and as I analyzed the issue using Structure101 I think I found > why, and what to do about it. > > Basically, entities have structure. Yeah, we already know they have mixins, > which assumes internal structure, but there's more to it than that. The DCI > paradigm suggests that we think of objects from two perspectives: > what-the-system-is (passive) and what-the-system-does (active). The first is > a structural concern (nouns) where the latter is an interaction concern > (verbs). > > In the first category you will find concrete things (Organization, User, > Project, Task in my case) whereas in the latter you will find roles and how > they relate (Assignable, Assignee, Authentication, Delegatable, Delegatee in > my case). Mixins in the first category also tends to have methods like > "create","add","remove", which are used to build a structure of entities. > They don't "do" anything, apart from creating structures. Modifying > associations, mostly. > > The category contains mixins with all interactions, with objects being > represented by roles. Interaction methods will rarely change the structure > of an existing object graph, just "do something" with it. > > Dependency-wise, the structure, what-the-system-is, may only refer to > concepts within the structure. An Organization may refer to a Project, but a > Project may not refer to an Assignable, since that would be mixing structure > and interactions. The consequence of this is that interactions can be used > on any object graph that fulfills the roles, and may have nothing at all to > do with Organizations, Projects and Tasks, as is the case in my project. > Also, as DCI predicts it becomes possible to "read" an interaction algorithm > without looking everywhere in the code. If I want to find out everything > there is to know about "assignment" I can read that interaction+roles, and > I'm done. I don't have to look in the entity structure that "implements" > this interaction. Similarly, the interactions may only refer to interaction > concepts, even though structure and interactions both coexist within an > actual entity. An interaction refers to "Assignable" instead of "Task", and > "Assignee" instead of "User". The Task entity Composite interface refers to > both Assignable and Task interfaces though, as it is the "glue" between the > structure and interactions. For example: > interface TaskEntity > extends Task, Assignable, Delegatable. > { > } > > If an interaction requires an entity to implement a role that needs access > to the structure, then this is done in the "glue" layer (same package as > TaskEntity above). So structure refers to structure, interactions refers to > interactions+roles, and then actual entities bind things together, including > implementing interaction roles using the structure. Then there is no tangle, > as structure and interactions are separated yet coexisting without > explicitly knowing about each other. > > Compared to current "best practices", the structure would be comprised of > our anemic POJO domain model (the create/add/remove methods), and then the > interactions would be implemented by transaction scripts that work on these > graphs. They would most likely be completely meshed together though, with > interactions referring to "Task" instead of "Assignable", so there's no way > to read the algorithms, and no way to compose algorithms. There would also > be no logical place to handle polymorphism. > > To me this is a big step forward, and shows just how important it is too > have mixins as a conceptual tool, and how to use them properly for different > things. > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
