OK, very good.
We're off running in this next section, so this is going to be about we just talked about models in
general, so let's narrow down it a little bit and talk about what I call domain models.
So what is a domain model and what is a domain?
So a domain is the thing that enclose the content of a particular field of knowledge.
So we talked, for example, about the concept used to describe and understand you to me before.
So we talked about commerce and curriculum and section and lectures and lecture completion rate, for
instance, and so on and so on.
A user's students, those are all part of the udemy domain.
Right?
So the Unimin domain is the thing that encapsulates that whole area.
So it is the boundary around a particular knowledge field and it's kind of recursive.
So, for example, we can talk about retail banking, right?
We can talk about in the broader sense, there are all kinds of different types of banks.
Right.
And all the banks, the individual banks are actually part of a even larger domain national bank and
which includes the central bank maybe and other institutions that are important in this and the regulatory
institutions and so on.
And then we can narrow it down and say within retail banking in general, we can talk about the specific
retail bank so we can narrow and broaden the scope of a particular domain.
Right.
So that's the kind of recursive ness of it.
It's like a Russian doll, but it's also layered in abstraction.
So, for example, I can talk about a particular subject and I maybe can talk about it using terms and
concepts from biology so I can describe it using terms like cell DNA and so on.
I can also maybe describe the same thing, but using terminology more from chemistry, like talking
about molecules or reactions and so on.
And you see, there is no worry.
It's not a it's a little bit of a gray scale.
Which concepts are part of biology and chemistry here.
But I think you get the point.
I can talk about them using kind of more physics concepts like an atom and force CIS and so on.
And I can even understand maybe using quantum physics terms here, like spins and quarks and so on,
so you can actually describe the thing on different levels of abstraction.
So the recursive nature was more like that.
You can broaden the scope and can talk about more things, but you can't on the same abstraction level
and then you can actually go up and down in terms of abstraction as well.
So what is then a conceptual domain model?
So that model should try to encapsulate the experts knowledge and expertise language so any domain can
be described on a conceptual level.
And we understand that now because we see that most of the conserver actually stuff that we create.
So they are status functions that we actually jointly agree on exists.
So it includes the concept used by the experts in that particular domain, and they use it to create
and understand and develop theories and systems within that domain.
So that's the language to use to express both current situations and future problems and maybe also
future solutions to those problems.
And the interesting thing here is that depending on who you are, you will have different.
Of course, the experts will have a lot of different concepts in their domain.
So take this particular example.
So it's like maybe a programmer or a hardware guy and he will have understanding about what the processes
and the thread and file and memory and pipe network and CPU.
Right Seargent.
They will have a conceptual model and domain model, including words like pacemaker, tachycardia,
artery, scalpel, scissors and so on.
A banker would have terms like investment loan, syndication, interest and annuity.
However, what is a little bit interesting about this is that there is also a distinction that people
use.
And when we talk about problem domain in solution domain, so the conceptual model is explicitly chosen
to be independent of design and solution concerns.
So, for example, if you have this banker, he would think in terms in his problem domain, in terms
of priority agreement, payment, asset and product, so to speak, but maybe the solution domain will
be creating maybe an I.T. solution for this.
We need to talk in terms of a Java component called party database table that is implemented using a
skill that is called party, maybe something called hibernate, and that is dependent on the general
concept of a Java class and so on.
So those concepts are very tied to what it is to be programming
and creating a solution for that domain.
So they are said to be part of the on the solution domain instead.
However, what is important here is that this problem solution distinction is is relative.
So it depends on who you ask.
So if you ask this business person here, they will probably say that this party agreement, payment,
loan, Hassidim products part of the problem domain.
And but if you ask the programmer, they might say that the problem domain for them is actually Java
component and hibernate in part in Eskil, because from the hardware guys perspective, that's a problem
domain because the solution domain is actually just talking about files and a type of the file is an
executable that creates a process and a process can include multiple threads and so on.
So that's kind of a solution to Maine for that problem to Maine.
So this is actually in the eye of the beholder, actually, if it's a solution to Maine or a problem
to Maine.
And that's actually quite important to have in mind, because sometimes people can start arguing about
whether something is part of the problem domain and some of it's part of the solution to Maine that's
depend on where where are you, where you have your perspective kind of.
So what is then a business domain model, so a business domain model?
It includes the concept that a business experts use and which it doesn't have to be named, said a business
expert, to be kind of the general barriers of all that language, so to speak, and the language and
the terms and concepts they use to think about this, to understand it, and to create new scenarios
in within that domain.
Those concepts are part of the business domain.
It's usually independent on any organization or exactly how it's executed or software systems.
So usually in terms include the the.
That in the Arabic language, more and more or less, and that language could be used to implement it
in different ways usually, and it's also detailed to a level that makes sense for the business expert
so they can actually execute all the business logic that is needed using the terms.
So it's actually if it's not including enough concepts, then they cannot describe all the business
logic, but it usually doesn't include more concerned than they need.
And that's also why languages tend to grow when the business grow.
It's not only information that is this is also a huge mistake, I would say that sometimes people think
that it's only stuff that we actually store in our databases to report our part of our domain business
domain model.
But you really need to think about a lot of other stuff as well.
So take the simple example.
You have a person that is concerned about what is of being actually a person, a real world person like
this.
So an instance of a person is a real person, right?
Then you can have a concept of person information, which is information about that person.
And an instance of that is not a person.
That's a kind of chunk of papers with ink on it, probably.
So we could have both the concept of a person of information about a person and the concept of a person
in our business domain model.
If they are important and we shouldn't.
It's a little bit confusing to try to mix them into one concept because then you have a hard time actually
deciding what instances there exists based on that concept.
So business concept models do not just include what we have in our databases.
That is also important, even if a large chunk of it might be represented in databases as well.
Very good.
So that was the second lecture in this section we're going in, the one we talked about domain models,
more generic.