DCI, trouble with concept of 'context' and what roles within know of each-other - interaction

I may just be missing a key concept here. I understand the 'dumb' data objects. I also understand that roles are stateless collections of methods applied to a dumb object when it takes on that role. I also understand that a context assembles the actors that will take place in the algorithm being implemented. But what the roles know about each-other, and weather they must be defined within the context, or outside it is unknown to me.
Say a context has 2 roles, start and end. Our use-case is string concatenation, so we will be assigning a string to each role.
some psudocode:
context concat {
role start {
method concat() {...}
method get_value {self->as_string}
}
role end {
method get_value {self->as_string}
}
// According to the docs I have read, the context simply kicks off a method in
// a role, the role handles the rest.
start.concat(?)
}
Now for 3 different combinations of how concat() (the method) and start.concat(?) (the call) may need to be:
Roles are aware of other roles in the same context (forcing roles to be non-reusable in other contexts, which seems wrong to me.)
concat{ self.get_value + end.get_value }
start.concat() // Not passing 'end' as an argument,
// it is already aware of end because
// it is defined in the same context
Roles are not aware of the other roles in the context, and thus need them passed in as arguments (Which seems a pain as a context could have any number of roles, if the context starts by kicking off a method we could need to pass 30 'roles' into the one method call as arguments, then chain them all the way!)
(Note: In this one the role definitions may be moved outside the context, and re-used in multiple contexts)
concat( end x ) { self.get_value + x.get_value )
start.concat(x)
To me the most obvious choice seems to be to not force context to kick off a method and nothing more. Then put the interaction logic into the context, and the non-interactive parts into roles. (Note: In this one the role definitions may be moved outside the context, and re-used ina couple of contexts)
concat() UNDEFINED
start.get_value + x.get_value
This seems to contradict this though:
http://en.wikipedia.org/wiki/Data,_Context_and_Interaction#Execution_Model
the Context invokes a Role method on the first object to take part in the use case.
From that point forward, Roles invoke each others' methods to carry out the use case.

In DCI the roles are usually aware of the context, and the context can act a repository for all the relavant roles. I.e. case number two where the role can access the context, and ask it for the objects playing the other roles it needs.
This is implementation detail though. Passing the needed objects into role methods can work too. The important part is that the roles interact with each other through the role methods (that is, not through role player methods, since that creates an unfortunate coupling).
Roles are - generally speaking - not expected to be candidates for reuse across contexts. A context roughly corresponds to a use case, and the roles implement the behavior of the use case. In general that logic is not reusable across use cases.
Hope this helps.
Also you may want to check out the artima article introducing DCI, and the object-composition google group.

Related

Validity of domain entity method based on context or caller

I am currently reading about DDD and have a issue how to implement a certain validation.
Scenario:
I have an entity Group that contains a list of Members which in turn consists of a User and a MemberState (Member, Admin). The entity has a method MakeAdmin(User user) that turns a member into an admin.
The rule is: Only if the current user is admin of the group, it is allowed to turn the member to an admin.
I have three possible implementations in mind, with some caveats each.
Variant 1
Group enitity gets a dependency IUserContext injected via constructor to get the current user. With that the entity can check if the current user is admin and is allowed to switch the member state.
Caveat: I don't like that the domain entity has such a dependency injected and I don't think that is correct in a DDD view.
Variant 2
Method MakeAdmin() gets an additional parameter which turns it into MakeAdmin(User user, User currentUser). That removes the requirement for the IUserContext dependency in the entity.
Caveat: I am not sure if it is correct at all that the entity validates this rule, because it is not really an invariant of the entity.
Variant 3
Validate this rule in an application service, and only call MakeAdmin(User user) if validation passed.
Caveat: I consider the rule domain specific, so I think it is not correct to put it in application layer.
So what would be the best option, or is there some totally different variant?
My suggestion would be to go with your third option: Authorise access in the application/integration layer and then call into the domain.
This goes for any domain functionality really. The domain should not concern itself with whether the action may or may not be performed based on authorisation but rather only with domain concerns. If that authorisation action happens to be a domain concern in a particular Identity & Access Control bounded context that it would make sense but you would not run into those too often.

Can one use composition in Rails to create an object that has an interface including the methods of its composite objects?

I'm attempting to solve a domain modelling problem in a Rails application via composition.
I have a generic active record User class (which has some attributes in the users table), but we have a few different flavours of user. Some of these different user types have data stored in different places (for legacy reasons).
For example: BlueUser objects have their email attribute stored in the DB.blue_users table, and RedUser objects have their email stored in DB.red_users. Note that blue_users and red_users do not have the same table structure, they just both happen to have an email.
My intention is to have the generic User class be the only to interact with, and use composition to "create" the User objects out of their own properties and methods, in addition to the properties and methods of the composite object (Let's call it the User_Record object).
So the User class would have its own methods, but then at runtime as the User is being instantiated (perhaps via after_initialize), a RedUser or BlueUser object may be instantiated within User as the User_Record object. Each of the User_Record objects/implementations would be Active Record models themselves. I'm then hoping that something can be done so if I ask for the property User.email, it can be pulled from the User_Record object (without having to call it like User.record.email).
I've looked a little bit at composed_of in Rails, but am unsure how I might go about unifying the properties / methods of the two objects (so that I wouldn't have to do User.record.email elsewhere in the codebase).
I hope my explanation is clear, but if not I'd be happy to take another stab at it.

How many DbContext subclasses should I have, in relation to my models?

I'm learning ASP.NET MVC and I'm having some questions that the tutorials I've read until now haven't explored in a way that covers me. I've tried searching, but I didn't see any questions asking this. Still, please forgive me if I have missed an existing ones.
If I have a single ASP.NET MVC application that has a number of models (some of which related and some unrelated with each other), how many DbContext subclasses should I create, if I want to use one connection string and one database globally for my application?
One context for every model?
One context for every group of related models?
One context for all the models?
If the answer is one of the first two, then is there anything I should have in mind to make sure that only one database is created for the whole application? I ask because, when debugging locally in Visual Studio, it looks to me like it's creating as many databases as there are contexts. That's why I find myself using the third option, but I'd like to know if it's a correct practice or if I'm making some kind of mistake that will come back and bite me later.
#jrummell is only partially correct. Entity Framework will create one database per DbContext type, if you leave it to its own devices. Using the concept of "bounded contexts" that #NeilThompson mentioned from Julie Lerhman, all you're doing is essentially telling each context to actually use the same database. Julie's method uses a generic pattern so that each DbContext that implements it ends up on the same database, but you could do it manually for each one, which would look like:
public class MyContext : DbContext
{
public MyContext()
: base("name=DatabaseConnectionStringNameHere")
{
Database.SetInitializer(null);
}
}
In other words, Julie's method just sets up a base class that each of your contexts can inherit from that handles this piece automatically.
This does two things: 1) it tells your context to use a specific database (i.e., the same as every other context) and 2) it tells your context to disable database initialization. This last part is important because these contexts are now essentially treated as database-first. In other words, you now have no context that can actually cause a database to be created, or to signal that a migration needs to occur. As a result, you actually need another "master" context that will have every single entity in your application in it. You don't have to use this context for anything other than creating migrations and updating your database, though. For your code, you can use your more specialized contexts.
The other thing to keep in mind with specialized contexts is that each instantiation of each context represents a unique state even if they share entities. For example, a Cat entity from one context is not the same thing as a Cat entity from a second context, even if they share the same primary key. You will get an error if you retrieved the Cat from the first context, updated it, and then tried save it via the second context. That example is a bit contrived since you're not likely to have the same entity explicitly in two different contexts, but when you get into foreign key relationships and such it's far more common to run into this problem. Even if you don't explicitly declare a DbSet for a related entity, it an entity in the context depends on it, EF will implicitly create a DbSet for it. All this is to say that if you use specialized contexts, you need to ensure that they are truly specialized and that there is zero crossover at any level of related items.
I use what Julie Lerman calls the Bounded Context
The SystemUsers code might have nothing to do with Products - so I might have a System DbContext and a Shop DbContext (for example).
Life is easier with a single context in a small app, but for larger application it helps to break the contexts up.
Typically, you should have one DbContext per database. But if you have separate, unrelated groups of models, it would make sense to have separate DbContext implementations.
it looks to me like it's creating as many databases as there are
contexts.
That's correct, Entity Framework will create one database per DbContext type.

Ok to have unbound roles in a DCI Context?

I'm working on a CreditCardPayment context, and found this possibility that not all roles are needed for some context methods. For example, the method CreateSecurityHash may require all roles, but VerifyHash only requires one. Is it ok not to bind all roles? If so, what about introducing multiple constructors and only bind what's needed, like this:
public CreditCardPayment(objectA, objectB, objectC)
{
BindRoles(objectA, objectB, objectC)
}
public CreditCardPayment(objectA)
{
BindRoles(objectA, null, null)
}
It feels difficult though to know what context methods are allowed to call when doing this. So I'd like to know:
Is this still ok (if so, why?), or
Is the whole scenario a sign that another context is needed, or
Should I keep the context and supply all objects needed for the roles, always?
If you feel like not binding all roles there's a few questions you should go and ask your self. You've already asked one of them "Should I create two contexts?" to answer that question I'd look at the context as a hole. If it does indeed model one process then don't divide that into several. We wish to model the end users mental model. If that model is complex there's nothing we can do to change that but we can help by reflecting it.
In your particular case it would seem that you are indeed modelling one process in which case you should keep the context as one. Boind the roles once and know that from that point on you are safe to call use the interactions.
Not binding roles will lead to code that is unnessecarily hard to reason about. "Will it be safe to call this method?" you will only be able to answer that at runtime when you can see which roles have been bound. All roles are always bound at the same time at this happens prior to the interaction or is the first part of the interaction

When to create a class vs setting a boolean flag?

I have an interesting question to pose; when should one create a model class/object as opposed to setting a boolean flag for data stored in a database?
For example, say I have a Person class that has boolean flags for President, Guard, and PartTime. This class/model is treated differently depending on the value of the flags. So the President gets different privileges in the system from the Guard and from the PartTime(r).
When would one use Single Table Inheritance to represent this information and when would one just continue to use the boolean flag?
My instinct is to convert these to different Objects using STI since this seems more OO to me. Checking booleans seems wrong in some way, but I can also see a place for it.
Update for clarification
Let me use another example because the one above has too many cases involved with it.
I am working on a CMS application that contains Pages, a Page can be Public, Private, Shared, Hidden, or Default (meaning it is what you get when you don't specify a page in the url). Right now, we have a Page model and everything is a boolean flag - Public, Default, Shared.
I am not convinced this is the best method of handling this. Especially since we have rules governing what page can be what, i.e., the Default page or a Shared page must be a Public page whereas a Private page is just Private.
I agree with the comment below that Roles for the Person example makes a lot of sense. I am not sure that for the Page example it does.
And to make things more complicated, there can only be one Default page and one Shared page. STI may allow me to validate this, but I am not sure since there can be many default and shared pages in the table (just not associated with a particular site).
Note: The context for the question is a Ruby on Rails application, but is applicable for any object-oriented language.
First of all, let's establish what single-table inheritance typically is used for. It is a way to combine the storage and behaviour of multiple things that resemble each other. Sticking to a CMS, an example would be a table with posts, which could be either a Comment or an Article. They share similar data and behavior, but are ultimately different things. Whether or not something is a comment is not the state of the object, it's an identity.
In your example, however, whether or not a page is public or private, shared or not, or hidden, appears to be a part of the state of the page. Although single-table inheritance might technically work (provided all subclasses are mutually exclusive), it's not a good fit.
State should be implemented in one or more columns. An attribute that represents a certain dual state can be specified as a boolean; yes or no. If a page always is either private or public, you can model this as a single boolean column, private. If it's not private it's public (or the other way around).
In some cases you may want to store three or more different states that are mutually exclusive. For example, a page could be either private, or public, or shared (I don't know if this is the case -- let's pretend that it is). In this case a boolean will not help. You could use multiple boolean flags, but as you correctly observe that is very confusing. The easiest way is to model this as an enumeration. Or when you lack this (as is the case with Rails), simply use string values with a special meaning and add a validation that ensures the only values you use are one of private, public or shared.
Sometimes certain combinations of different state variables are invalid. For example, a page might be a draft or approved (reflected by a boolean column approved); and it is also either public or private (also reflected by a boolean column). We could decide that a page should must be approved before it is made public. In this case we declare one of the states invalid. This should be reflected by the validation of your model. It is important to realise that a draft, public page is not fundamentally impossible, it's only impossible because you decide it should not happen.
When creating your model, make a careful distinction between the attributes that reflect actual properties and states of the subjects in the real world, and the business rules that determine what should be possible and what shouldn't be. The first should be modelled as columns, the second as validations.
Original answer:
One obvious difference is that boolean flags allow a Person to be marked as president and guard at the same time. If your model should allow these situations, single-table inheritance will not work for you.
On the other hand, maybe a Person that is a president behaves differently from a regular person; and a single person can only be president or guard. In this case inheritance may be a better fit. I don't think you should model "part time" as a subclass, though. That is an attribute in any case.
There is also an important third option, one where you completely separate the job or role of a person from the model. One person has one (or many?) jobs, which are or are not part-time. The advantage of this model is that you separate attributes of a person from the attributes of their job. After all, people change jobs, but that does not make them literally a different person. Ultimately this seems to me the most realistic way to model your situation.
I prefer not to use a flag for this, but also not to subclass Person for this. Rather, attach a Role (or if you have someone who's both a President and a Guard, a set of Roles) with subclasses of Role governing the prvileges.
Personally, I am neither a President nor a Guard, but I am both a Programmer and a Musician, and have a few other roles at times (in fact, I was a Guard for a while simultaneous with being a Student many years ago.).
A Person has-a Role.
I have found that whenever I think "Hm, I have these 3 types of behavior and they do look like subclasses, but need to change at runtime", look at a strategy or state pattern. It usually fits very well and usually also beats a simple boolean flag with respect to keeping responsiblities apart.
In your case, this heuristic would say that you have a Person with an attribute of type AccessRights, which decides if a certain action can be performed or not. Person either gives access to this object or delegates appropiate methods. After that, you have PresidentialRights, GuardRights and PartTimeRights implemetning this AccessRights interface and you are good to go.
Given this, you never need to change the person class whenever a new type of access right appears, you might need to change the person class if a new type of action appears (depends on if you delegate and how you delegate) and in order to add new types of AccessRights, you just add new implementations of AccessRights.
the answer is that it is basically a design decision. There is not an a priori right way of designing an architecture. When you define classes and relationships among them you define an architecture and, at the same time, a language representing the domain of your application.
As any languages it consists of a vocabulary (i.e. Person, President, Guard, etc.); a Syntax (i.e. the relationships you can specify for the instances of your vocabulary) and Semantics (i.e. the meaning of the terms you specify in vocabulary and relationships).
Now you can obviously obtain the same behaviour in possibly infinite way. And anyone would come up with a different architecture for the same system since anyone might have a different way of thinking at the problem.
Despite this there are some criteria you should take into account when designing.
When you define a Class you are defining a "first order" construct of your language, when you define attributes for a Class you are describing the characteristics of your first order constructs.
The best way to decide if you need a class or an attribute might be this.
Do Presidents and Guards have different characteristics apart of those they share since they are both person? If that is the case, and they have a number of different characteristics you should create two classes (one for the President and one for the Guard)both inheriting from Person. Otherwise you have to collapse all the characteristics (those belonging to person, those belonging to President and those belonging to Guard) in the Person class and condition their validity to another flag (type). This would be a very bad design
The characteristic of a Page of being public or not is instead something which actually describes the status of a page. It is therefore quite reasonable to model it as a Property of the Page Class

Resources