Use case <-> Context mapping

[Alexandre Gravem]

I was watching a video[1] where Cope talk with Uncle Bob Martin about TDD. It's quite old and Cope's views might have changed but some things caught my attention. And I would like to clarify them through the perspective of DCI (which I believe was nascent at the time). So here are the quotes:

"[...] if you try to do things incrementally [...] driven by your interaction with the customer, without domain knowledge upfront, you run risk of doing it completely wrong"

So, as I write the context that implements a use case, I'm gonna also take into consideration the needs of other stakeholders (that I know are interested because of my domain knowledge). Those stakeholders will eventually have use cases written where their needs are central. But, knowing that the time will come, it's ok to prepare for it. Would it then be right to say that not all roles in a context are directly derived from the use case it represents? Am I completely wrong about my assumption of a 1:1 mapping between Context and Use Case?

"If you do a real banking system, savings account is not even an object [...] what a savings account is, is a process [...]"

And I believe today Cope would refer to it as a context instead of a process. What I understand he meant with "is not even an object" is that it's not one of those dumb data objects defined by a class in trygve. That got me thinking about the domains I've worked with and how a lot of central concepts are miss represented as objects. I've worked a lot with ecommerce. From the point of view of fulfillment, order is not an object, it's a process touched by payment, invoicing, picking, packing, shipping, etc. In a particular shop even the shopping cart was designed as a long running process. I worked with education, and a exam wasn't just a bunch of answeres. We would log all the times a student changed the answer other behaviours and with that info educators could improve lessons. 

So thinking how I would organize a DCI project, I'm seeing this recursive structure. At the top there are the contexts implementing the end-user facing use cases. Those contexts are going to have some objects to interface with the user, but it seems to me that most of the core roles are going to be played by other contexts (that I know are contexts because of domain knowledge) and at the bottom I'm going to have contexts with roles played by objects, probably interacting with databases or messaging systems.

Is this accurate or just a coincindence that most core concepts can be seen as processes and not objects. Is it relevant?

Sorry if I read too much from old quotes. I don't want to waste anyone's time with ramblings. I'm new to DCI and most of this mail is probably nonsense. The tipical response is RTFM, so I bought and started reading Cope's book today. I promise more productive interactions in the future.

Cheers.

Alex Gravem

[1] https://youtu.be/KtHQGs3zFAM?t=7m17s

[Rune Funch Søltoft]

I’m not entirely sure what you are trying to describe. Care to mock it up in trygve?

Mvh

Rune

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.

[gra...@gmail.com]

Hej Rune. I'm gonna try to come up with an example.

Thanks

You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/GlKtBmFxPDw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.

[Matthew Browne]

On 1/9/18 8:24 PM, Alexandre Gravem wrote:
> Is this accurate or just a coincindence that most core concepts can be
> seen as processes and not objects. Is it relevant?

It's all about mental models. If implementing a data object as a Context
allows you to reflect one of the stakeholder's mental models that's
important to the application, then yes, that would be the better way to
model it in DCI. Otherwise, a dumb data object is probably fine. In the
case of the money transfer example, the Account context expresses the
mental model of the accountant.

[James O Coplien]

Den 10. jan. 2018 kl. 10.24 skrev Alexandre Gravem <gra...@gmail.com>:

I was watching a video[1] where Cope talk with Uncle Bob Martin about TDD. It's quite old and Cope's views might have changed but some things caught my attention.

They are probably even more extreme now ;-)

And I would like to clarify them through the perspective of DCI (which I believe was nascent at the time). So here are the quotes:

"[...] if you try to do things incrementally [...] driven by your interaction with the customer, without domain knowledge upfront, you run risk of doing it completely wrong"

So, as I write the context that implements a use case, I'm gonna also take into consideration the needs of other stakeholders (that I know are interested because of my domain knowledge). Those stakeholders will eventually have use cases written where their needs are central. But, knowing that the time will come, it's ok to prepare for it. Would it then be right to say that not all roles in a context are directly derived from the use case it represents? Am I completely wrong about my assumption of a 1:1 mapping between Context and Use Case?

I think that one accommodates concerns outside any given use case with a good domain model and a good class architecture. I don’t think one has to adjust for future use cases when implementing any single Context.

"If you do a real banking system, savings account is not even an object [...] what a savings account is, is a process [...]"

And I believe today Cope would refer to it as a context instead of a process. What I understand he meant with "is not even an object" is that it's not one of those dumb data objects defined by a class in trygve.

You understood me properly. At the time my choice of words was a bit sloppy but you got the gist.

That got me thinking about the domains I've worked with and how a lot of central concepts are miss represented as objects. I've worked a lot with ecommerce. From the point of view of fulfillment, order is not an object, it's a process touched by payment, invoicing, picking, packing, shipping, etc. In a particular shop even the shopping cart was designed as a long running process. I worked with education, and a exam wasn't just a bunch of answeres. We would log all the times a student changed the answer other behaviours and with that info educators could improve lessons. 

Perfectly analogous to what I was relating with respect to the Account example.

So thinking how I would organize a DCI project, I'm seeing this recursive structure. At the top there are the contexts implementing the end-user facing use cases. Those contexts are going to have some objects to interface with the user, but it seems to me that most of the core roles are going to be played by other contexts (that I know are contexts because of domain knowledge) and at the bottom I'm going to have contexts with roles played by objects, probably interacting with databases or messaging systems.

I dont think it’s as hierarchical as this suggests but the general idea strikes me as correct. I don’t see many Context instances as role-players in most implementations, but there are some.

Is this accurate or just a coincindence that most core concepts can be seen as processes and not objects. Is it relevant?

I think it is a choice of upbringing and mental models. Constantine and Yourdon would view split the world into data and processes. Humans can reify anything, and if you want to reify any process as an object, I guess one can do that. I guess the question is whether the resulting Context can support a set of tightly coupled (for some definition of “coupling”), closely related operations. If it supports only one, then it is likely to be a Context; if several, it is likely to be an instance of a class. There are exceptions, including Account (where the class is TransactionLog).

Sorry if I read too much from old quotes. I don't want to waste anyone's time with ramblings. I'm new to DCI and most of this mail is probably nonsense. The tipical response is RTFM, so I bought and started reading Cope's book today. I promise more productive interactions in the future.

At the ideal answer is which one best supports the architecture test: i.e., which one will cause the fewest relationships to be cut or re-done under evolution, and which one best reflects human understanding of the phenomenon. At one extreme there are heuristics that start with the very vulgar consideration of data (for which one would use classes) versus use cases (for which one would use Contexts). At the other end of the spectrum you can hypothesize that all activity goes into Contexts, and that all “state" is associated with primitive types like Boolean and Integer (i.e., value types instead of object types) — and that classes completely go away. (I put “state” in quotes because you can think of the integer constant 1 as a function that produces a constant value. A battery produces a value (voltage) of 1.5 volts — a fine value, though there is no meaningful state.

Cheers.

Alex Gravem

[1] https://youtu.be/KtHQGs3zFAM?t=7m17s

[gra...@gmail.com]

@Matthew you are absolutely right, I missed the relation to mental models.

@Cope thanks for the detailed answer, it was spot on and put those question to rest while giving me more food for thought.

Cheers.

Alex.

You received this message because you are subscribed to a topic in the Google Groups "object-composition" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/object-composition/GlKtBmFxPDw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to object-composit...@googlegroups.com.