Concepts, Entities, Data

Domain?

Imagine we are starting our new gig and he are in the middle of the discussion with the customer.

(you can interact with the "tabs" below)

What is your gut feeling, dear Reader?

Should we have one single table Task or one table for each: SupervisedTask, ComplexTask and QuickTask?

Then probably we would need to represent QualificationCard, Supervisor and Evaluation as separate tables too.

Ah, we almost forgot about multiple people contributing for ComplexTask - our customer didn't say a word about proper name of underlying profession, let's call them Worker.

Also, behind the scenes we got some more details that all types of tasks are related to common set of data, e.g. Worker.

Language is something that flows and goes, it isn't tangible, and might be volatile.

Let's sketch something.

Entity Relationship Diagram

As you can see, we are open for extension because we have tables for TaskType and TaskStatus, in case of changing mind by our customer. Smart, ain't it?

What's the problem?

You probably already know me a bit (I hope so, dear Reader!) - I like to exaggerate a bit.

I intentionally focused on nouns and completely forgot about asking hugely important questions:

• who are our users?
• how they are going to use our system?
• what is the current way of satisfying their needs?
• how this system should help them achieving their goals?
• etc.

Of course, I trivialized the example - guilty and charged.

But how often do we hear in our day to day conversations about statuses, status flags, entities, data models?

How frequently do we take the following premise: "two entities share similar set of data" and build an assumption that they might be represented by the same entity?

In our toy case, Task might be represented as a base class so that we are avoiding data duplication.

No one would disagree that QuickTask is a Task, right?

In the search for relationships

We looked for hierarchies, how things related to each other.

If we Slow down and ask ourselves - what did our imaginary customer describe?

Out of the unstructured, analog, audio signal that we call sound, we interpreted the words and made them a little bit more structured.

Immediately focusing for nouns, relationships between them, and possibly paying attention to attributes (also called data).

In fact, seeking all of them is facilitated by thinking in terms of Entity Relationship Diagram (ERD), which might be connected to efficiently representing entities and data in the persistence tools like SQL databases.

This might be considered as a quite low level, when it comes to modeling.

It's just one level (Being) - and there are more. (why am I calling it a level? Check Modeling Maturity Levels)

What was first: Entity or Entity?

Before diving into sketching of the ERD, let's think about what we have heard in the discussion from the beginning of the tale.

How would we call all of the highlighted "things"?

The first and foremost label that people use to call those "things" is Entity.

Each Entity has Data related to it.

This word is biased and easily might anchore us in very specific, narrowed thinking.

To avoid entangling our minds with TDD and DDD (Table-Driven Development and Database-Driven Design), I like to use another word.

I like to use Concept label for those "things".

"It's just a Concept" - I don't know what will be the technical realization of it.

I expect nothing, so I am prepared for everything.

Not being bound, by anchors coming from the persistence realms, liberates.

We can now break the rules.

What is the nature of a Concept?

We don't need to ask ourselves "how many Equipments can a Task have?" - it's secondary.

We don't need to think whether a QualificationCard has name and what is the max lenght of it - this won't cause problems.

Concepts don't have statuses, Entities do.

Taking that into account, we might play with the names of the concepts - is there a place for Completed Quick Task? Would it differ from Completed Complex Task?

Remember, we are not talking about technical implementation yet!

In my head, concepts can naturally emerge and die - not literally, of course.

They can come and go by being transformed from one to another.

They are processed, they evolve into other ones.

Can a quick task become a complex one?

Let's imagine that our customer, being asked - "is it possible that a quick task won't be able to be finished because it has some unexpected complications?".

Assume, the customer replied: "Yup, then task type is changed from 'Quick' to 'Complex'."

(although there are business people that were harmed with Database-Driven Design - we need to help them)

Sorry to say, but this doesn't sound like a Language of the problem, at all.

With high probability, the answer would be a bit different: "Yes, the quick task might eventually become a complex one".

"Become a" - very important expression - the highest possible level from Modeling Maturity Levels.

If we carefully listen to ourselves, we express various concepts from our day to day life exactly in the form of transformations.

Neverending arising and ceasing.

Sooner or later we might realize that it's very natural for us to think of, e.g. an important document to become "signed" or an old sandwich in the backpack to become "rotten".

Thinking with concepts gives this possibility, at least in my opinion.

Concepts do not compile

Yup, concepts are the first step - they don't throw any errors or cause the servers to go down (or do they?).

Of course, we might be judged that we are creating unnecessary complexity.

Someone might say - "you are complicating things that were simpler before!".

The cost of modeling increases!

Concepts allow to model "things" around the Language of the problem - no one says we must manifest everything in the code.

Considering that I don't know - what if our concepts do not have relational nature, but graph one?

Maybe there are no relationships as we know them from SQL databases.

How do we persist our concepts and how do we represent them in the application - those are totally different questions that we will need to ask ourselves at some point.

They will come, no worries.

From lines to arrows

Let us come back to our little case with quick task becoming complex one.

We know that complex task has some status related to it - right?

Knowing that, let's imagine our customer told us that they simply consider the following statuses as valid:

• ongoing
• assigned
• rejected
• blocked
• failed

Our Entity Relationship Diagram captured the static side of our "domain".

It has its own place - but not when "modeling the domain".

It might be massively helpful when we are working with relational databases, for example.

So let's now try to think of a combination of each "status" and complex task as a separate...Concepts.

Concept Map

Such web of concepts, in which there are no lines, but arrows, can be called a Concept Map.

It helps me with capturing the transformational nature of concepts, and model from the highest possible level - "Becoming" (you don't know what am I talking about? Check Modeling Maturity Levels).

What's more, there are high chances that there is an action that a user can do on Blocked Complex Task, but it cannot be applied to Assigned Complex Task.

Those are additional set of questions that we would need to ask for each of the concepts - and thankfully they are located in the "middle" level of Modeling Maturity Levels.

As you probably noticed, dear Reader, it highly resembles a finite state machine.

Try to tell your business people about finite state machine, I wonder what would be the reaction.

Data - what about it?

We shouldn't forget about very important aspects of each enterprise and human endeavour - data.

We could also call it information - just to break the anchors from persistence realms.

It is hugely relevant, and has it place - maybe not directly from day 0.

Each of the transitions, in our concept map, might require very precise set of details.

How we are going to store this information isn't the primary concern - or at least it shouldn't be.

Entity hater?

Am I Entity hater, moaning about the irrelevance of Data?

Well, kind of.

"Everything has its place, and there's the place for everything".

I think they might be irrelevant at the given stage, whereas during another one they play the most important role - and if we don't use our technical excellence, our users might not get the value from our system.

We shouldn't limit ourselves from exploring the concepts that manifest in the language, used by other human beings.

Our concepts do not have a boolean flag IsValid or IsActive attached, even though they might be technically implemented like that. (when talking about bools you might be interested in Bool considered harmful?)

When we move from concepts to entities, we might eventually talk about behavior, responsibilities.

Then we will probably transition from entities to data, because we need to have information to use.

Such process won't be discrete - it will, for sure, be turbulent, chaotic, fluid and full of emergence - the same as life is.

Next time, dear Reader, when you start you work, ask yourself a question: