- Damian Płaza
"Can you build it?"
Imagine we were challenged to build a software for organizing workshops.
Investor came and suggested that they have a brilliant idea and their novel approach will make millions.
Because of being a "yes-man" type of people, we said "yes".
We called them for another meeting in order to get proper details.
What is the relationship?
They started laying out the information (for your information: the "speech" is a raw stream of characters/words/sentences to simulate "real-life" conversation, or monologue if you wish - "real-life" means cognitive loading).
Investor: in our world, a workshop starts as an idea. An organizer tinkers about the possible schedule. By the way, this party is our target customer. Later, they will plan a detailed schedule, choose a premise and measure how many prospects are potentially interested in such a planned workshop. Each schedule will have a bunch of sessions, covered by teachers, but this will come only when they "approve" the workshop, based on the return of investment they can get. Given those workshop details, a workshop gets published so that people can sign up for it. Let's imagine that 100 people signed up. Statistically, 40% won't come so remaining 60% will be considered as "attending". This constitutes a workshop - people attending to a session conducted by a teacher. When workshop is finished, we are almost done. The last piece is actually "measuring" the workshop reception by getting "rates" - of course this can be done only after the workshop is finished.
Apparently, they were technical IT folks, who built many enterprise solutions.
The investor suggested drawing a data model in order to provide clarity what is related to what.
As we are experienced too, we focused on the entities, or nouns, if you will.
We weren't lazy so we got some additional questions about how those things are related to each other - as they suggested.
Now, the chaos started becoming tamed.
The orders began emerging.
As expected - a
Workshop is a central entity there.
What's more, we listened carefully and our model includes a possibility that a
Workshop can have no
Premise or no
Only when an organizer has an "idea" for a
Does our model cover that?
We are experienced developers and/or architects, we know how to deal with such a problem.
Now, finally, everything is complete - our model is flexible - we can model "a workshop, that is a mere idea, can have no attendees and no premise".
Status solves that and we can even write a specification, in the form of a test, for it:
should create a workshop with status 'WorkshopIdea' having no premise and having no attendees. (Curious why am I so explicit about specification and test? Please check "The ambiguity" of TDD)
How it evolves?
What do you feel right now?
Does it look familiar?
Can we, taking into account our data model, tell anything about what is possible? What activities, operations and rules are there?
We could argue - that's only a data model, it's a single view on the system.
Does it express what the investor was telling us? Sure - one might say.
If we wanted to look how the central "entity", a
Workshop, evolves - where could we find this information?
Possibly in the "user story" or in an "issue" in Github.
Maybe even in a executable specification as a test!
This data model expresses the static aspects of this small realm - a realm of how entities are related when thinking about workshop organizing.
When we look from a Modeling Maturity Levels perspective, we captured the reality in the form a
As a reminder for ourselves, each aspect is related to a set of questions one might use to model this aspect.
What it has? What does it consist of? What is it?
Clearly, we can say that, for instance:
Workshophas none or many
Workshopconsists of none or many schedules
Sessionhas one to three
But can we capture the problem space from a different level - still focusing on the main concept? (please pay attention I deliberately used a "concept" word instead of an "entity")
"Look Ma - no status!"
Let's try to pay attention to the language.
Our investor haven't used
Status in their stream of words.
What have their used? (play with the discussion by clicking on the tab titles)
Investor: in our world, a workshop starts as an idea. An organizer tinkers about the possible schedule. By the way, this party is our target customer. Later, they will plan a detailed schedule, choose a premise and measure how many prospects are potentially interested in such a planned workshop. Each schedule will have a bunch of sessions, covered by teachers, but this will come only when they "approve" the workshop, based on the return of investment they can get. Given those workshop details, a workshop gets published so that people can sign up for it. Let's imagine that 100 people signed up. Statistically, 40% won't come so remaining 60% will be considered as "attending". This constitutes a workshop - people attending to a session conducted by a teacher. When workshop is finished, we are almost done. The last piece is actually "measuring" the workshop reception by getting "rates"- of course this can be done only after the workshop is finished.
By carefully listening, we were able to capture the following group of words:
- "workshop idea"
- "planned workshop"
- "'approve' workshop"
- "workshop gets published"
- "workshop is finished"
- "workshop 'rates'"
Of course, there might be much more, but at least that's what we were able to find.
Let's draw them.
We used "nouns" with a "companion" - an "adjective". Just by doing so, the context got enriched.
Are they similar?
Based on the discussion we had, we know that each "workshop" might have some different details - or maybe differently named details?
Let's take the first one -
We know that it comes from an
Organizer and we can assume there's nothing more than a
Schedule (is it any Schedule?). Let's model it further.
We can assume, by knowing what our investor mentioned, when they think it's a good "idea", then they start working on a
Organizer checks how many
Prospects might be interested for attending.
Let's model that.
We know that when an
Organizer feels it pays off to run a
Workshop, they approve it and publish it so that people can sign up.
This is the time when teachers are appearing with a detailed schedule.
Let's model that.
Finally, when the time comes, a
Workshop is run - there are
Sessions carried by a
Then, when the time is up,
Eventually, people can rate the
Finished Workshop so it becomes
Let's see it.
"Where are my relations?"
I hear you, my dear Reader: "where are the lines?", "what are those floating gizmos?!" (or am I hearing myself?)
Is there any point to put lines?
I believe one could get the feeling of what is communicated through this little "model", even without "lines".
Actually, the lines might no longer exist.
Why? Because we don't need lines. We need arrows.
Suddenly, instead of a "static" relations, we got a flow, a direction.
Our model stopped envisioning structures and started expressing the process.
It shows how "things" are getting transformed over a period of time (note that there's no timeline drawn!)
And where is our "friend",
"There is no spoon"
What if I told you there is no spoon, ekhm, status?
At least on this level.
We don't need it because we tried modeling domain concepts by capturing the language. Our investor didn't mention any status!
It still might appear and live a good life but in totally different plane.
Infrastructure - think of sending it over the wire or storing it in a database - "status" is a word that "infrastructure experts" use when it comes to mentioned activities.
Domain-Driven Design encourages modeling solutions around the language - and "status" has its place too - in the "domain" of the infrastructure.
Nouns = bad, Verbs = good
Modeling around behaviors, hence "verbs", was always a desired direction, however, not always followed.
We were skilled in "looking for nouns" when exposed to a problem to solve.
Behaving level (you don't know what I am talking about? Please check Modeling Maturity Levels) has its benefits when it comes to modeling.
Especially, when we compare it to
Nouns themselves are not "bad" or "not suitable", when we think of providing a model to a given problem.
They "just" need a friend - adjective.
By using adjective noun collocation, we might explore the concepts in their natural habitats, capturing the context.
Collocations are a pair or group of words which habitually appear together to convey a whole new meaning. We use adjectives and nouns collocations putting adjectives before nouns.
What naturally emerges from using this linguistic construct is a transformation of lines into arrows.
Semantic mapping - static perspective on vocabulary
There is a "technique" for mapping out all the words and vocabulary - it is called semantic mapping or semantic maps.
Semantic mapping is a visual strategy for vocabulary expansion and extension of knowledge by displaying in categories words related to one another.
Using it in the right context, brings clarity and understanding.
Various resources use something similar to explore and lay out vocabulary of the domain (for example: see in Object Thinking).
We, developers and architects, are pretty familiar with "entity relationship diagram", when it comes to "modeling" (modeling what?).
When we apply our knowledge about database tables design and semantic mapping - we might get something that resemble "entity relationship diagram".
"Lifeless" structures that "only" capture what is the best way of archiving them so that retrieval and searching will be optimized (here I am generalizing and putting some assumptions, but I hope you bear with the direction of thinking).
Behaviors, responsibilities, evolution and transformational nature are kept somewhere else (if any).
Concept Mapping - transformational perspective on vocabulary
As we saw in this little example, there is an informal way of capturing the essence of the language, used by human beings.
Each of the concepts, we explored, could potentially be a subject of a process.
With high probability, most of them have "CRUD"-like lifecycle and their evolution does not have any restrictions.
Looking at the rest of the concepts, from a
Becoming perspective, might reveal very interesting properties of the system that we are trying to model.
Let's then focus on this transformational, processing aspects.
Even when we study "process" word definition, we might get interesting insights:
a series of actions or steps taken in order to achieve a particular end.
Sequential in nature, actions driving "a process" to the terminal state. Pretty straightforward.
But this is a "noun"-based definition, and nouns are bad because they anchor ourselves at the "entity"-thinking, right?
Let's check "verb"-based definition!
perform a series of mechanical or chemical operations on (something) in order to change or preserve it.
Again, serial nature, but the end of the sentence sheds some light upon our thinking - "to change or preserve it".
If we take our tiny tale and have "transformational" perspective in our head, a "workshop" is being processed in a serial steps and each step "transforms" it, in some way.
As mentioned before, we are not using "lines" but "arrows" to emphasize this aspect.
To distinguish such "mapping" from semantic map (which, in the scope of this tale, is considered capturing "only" static aspect), we could call it a concept mapping.
Those are just labels and we shouldn't cling to them - names can come and go, meaning might remain the same.
Change, change never changes
Imagine that our investor comes and gives flattering comments about precise "entity modeling" by using adjectives, next to nouns.
They forgot to include one important fact, when it comes to organizing workshops.
"Sometimes we need to cancel a workshop", said the investor.
As we have "various workshops" at our disposal, we can be very precise in asking what does it mean "cancel" and what are the consequences for:
- workshop idea?
- planned workshop?
- published workshop?
- rated workshop?
After a brief thinking, one can be pretty confident that "cancel" has many meanings and consequences. So not every "cancel" is the same "cancel".
When such a fact occurs, it might bring manifold of the effects - depending in which state a workshop currently is.
We could even say that a given workshop "changes" into another by transitioning from one state to another.
All this lingo around state, transitions, effects, facts - or if you like - events, can remind ourselves that we are talking about pretty well-established "pattern" of computation.
From concept maps to state machines
Imagine, based on our investigation, that those states and transitions between them are possible:
Could you name the "operations" that might happen between any two states?
I believe that in "entity relationship diagram" it would be a little bit harder.
Of course, we could argue that there are places and occurences where such a diagram shines.
No doubt on that.
But, more we go into the "processing" aspect of our little domain, the more it makes sense to use transformational-oriented modeling techniques.
It's very easy to jump on the "it is easy" wagon and model (or even worse - start implementing, immediately!) solutions to the problems with "simplicity" in mind.
The worst part of this kind of reasoning is we are misinterpreting "simple" with "naive".
With high chance, the most of the problems, we would need to find a solution to, will require CRUD-like model.
What about the rest?
It might sound trivial and simplistic approach but I find it useful - even when it "just" comes to thinking.
Concept mapping might give a new life for using "nouns" when modeling.
It's very common for "business" people too - they got "infected" (by "us" - technical people) with "Status-Driven Thinking" so it might be very interesting exercise to show an alternative.
Burying the transformational nature of the problems won't magically vanish, as essential complexity might involve such a trait.
And, as mentioned during this tale, it might seem we are inducing a lot of effort and complexity. The cost of modeling will still be there.
The complexity doesn't disappear, it gets moved.
The question isn't "if" but "when" and "where".
Are you dare to pay, consciously?