Region things

[gene]

We do have quiet a list of regions in our wiki.
I now want to do some development of GamingEnvironments, and these do have a relation to regions.

We have listed different types of regions:

• countries (Germany, France, Canada, Japan, China)
• groups of countries ("German speaking countries")
• parts of a continent ("Southern Europe")
• continents (Europe, Asia etc)
• entry for "worldwide"?

Up to now we wanted to use regions in these parts of our data model:

• GamingEnvironment.OriginalRegion
• assigning titles of a GamingEnvironment to a region
• HardwarePlatform.OriginalRegion
• assigning titles of a HardwarePlatform to a region
• SoftwarePlatform.OriginalRegion
• assigning titles of a SoftwarePlatform to a region
• assigning sub-platforms to regions
• assign release to region
• assign release group to region
• assign person to region
• assign language to region
• assign region to region

Wow!

How can we deal with that complexity?
Which of the mentioned connections can be made to which type(s) or regions?
Is it e.g. possible to make a connection to a country and also to the continent of that country?

And the most important question I am asking myself these days:
Which *simple* thing with regions can I start developing on?
What do we need first and what later?

[MZ per X]

First of all, I think that Regions should be their own Bounded Context, because we need them in many parts of our data model.

We have listed different types of regions:

• countries (Germany, France, Canada, Japan, China)
• groups of countries ("German speaking countries")
• parts of a continent ("Southern Europe")
• continents (Europe, Asia etc)
• entry for "worldwide"?

This is not as complicated as it looks, I think. We have three basic items here:
1) Our basic data item is the country. I don't think that we need to be more granular than that.
2) The next item is the country group. Every group consists of two or more countries. Such a group can be a continent, a language group, a business region like DACH, or a political region like the EU.
3) And worldwide, which is technically a group of all countries, but should be treated specially.

Technically, all the three types above should be the same (one entry in the Region table), so we can link to any of them using the same facility. The problem here is that a country can theoretically belong to more than one region.

Wanna start implementing this BC, so we can enter regions into the database?

And the most important question I am asking myself these days:
Which *simple* thing with regions can I start developing on?
What do we need first and what later?

Since we already have GEs, you probably should start with the "Original Region" there, then move on to regional titles for GE's.

[gene]

I can understand your answer. But I don't like it

Let mot quote some sentences from Eric Evans (the "inventor" of Domain Driven Design):

When you care only about the attributes of an element of the model, classify it as a VALUE OBJECT. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the VALUE OBJECT as immutable. Don't give it any identity and avoid the design complexities necessary to maintain ENTITIES.

This article about the difference between Entities and Value Objects might also be interesting.

So I will try to create our regions as value objects. We don't need additional complexity to manage regions as real entities.

[MZ per X]

So I will try to create our regions as value objects. We don't need additional complexity to manage regions as real entities.

I understand the concept, but I don't fully understand the implications of this when it comes to Oregami's regions.

Will we be able to show a German user all games released in DACH, besides those released in Germany?

[gene]

So I will try to create our regions as value objects. We don't need additional complexity to manage regions as real entities.

I understand the concept, but I don't fully understand the implications of this when it comes to Oregami's regions.
Will we be able to show a German user all games released in DACH, besides those released in Germany?

I will create a solution that supports regions that a composition of countries, yes.
The question ist:
How does the user choose what kind of region he wants to connect e.g. to a title? We do have to separate "pure countries" from "contintents" and "other regions" (e.g. DACH).

Let's talk about adding a title to a gaming environment (GE).
1) the GE is created (only with some kind of "working title")
2) a title object (we called it "transliterated string") must be created somehow
3) the title object is connected with the GE
4) the user gives this new connection some properties (we have written this down here already):
- Title Type (original, inofficial, ...)
- time period start & end
- region

The last property is the one I am talking about here.
How should that exactly be presented to the user?
Shall we list all countries of the world? And how do we show the continents and other regions to the user?

It would be glad if someone could give me ideas about how this could happen in detail.

[MZ per X]

Shall we list all countries of the world? And how do we show the continents and other regions to the user?

My thoughts about this:

1) We don't need to start with every country in the world in the database. I don't think we will need every country in Africa to begin with, for example. But of course we will need an easy way to unlock new regions later on, without the programmers or admins needing to jump through hoops to do this.

2) TheLegacy doesn't have regional data, at least I was unable to find them. So when it comes to a possible data import from there, we are free as far as regions go, I think.

3) So, for our MVP , we should probably start with a small set of main regions that games are released in, to see if it works:

Worldwide
(Internet) ???

Europe
North America
Asia

DACH (German-speaking countries)

USA
Great Britain
Germany
Japan

4) Should we offer an "Unknown" region for the hard cases or the lazy users? We will probably need to do this.

5) We should present these few starter regions as a kind of tag list, so people can choose more than one for one title. Or should we offer a UI for one region per title?
If there's more regions in the database later on, we will have to think about a better UI for this. We should prolly look at some other projects, how they do this.

6) The regions within RetroCollect's database can be seen here.
The interesting thing is that they separate their data into "Zones" and "Regions, with double data in it.

7) We shouldn't forget the sourcing from the beginning.

[gene]

I am currently removing regions from our applications. Will make them new afterwards.

I had the idea of a better data model for "titles".
It could work like this:

1) bounded context GE: create a GamingEnvironment
2) bounded context TS: create a TransliteratedString ("title")
3) bounded context GE: assign the title to a GamingEnvironment *without* Region-Information
4) bounded context GE: create 1...n objects "TitleUsage" underneath the GE-TransliteratedString-Assignments, and these will each contain more information like e.g. the Region-infos

So the data model for GamingEnvironments will look like this:
GamingEnvironment ==> TransliteratedStringConnection [TS-id] ==0..n==> TitleUsage [Region]

This would also be great for the whole process of collecting "simple" data (raw titles) first, and add more detailed data (region infos for title usage) later.

Opinions?

[MZ per X]

I like the idea of going from simple to more complex. For step 3 we could only require "weak" sourcing like the link to a cover or something like this, while for step 4 we should then require better sourcing like a scan of the box, the medium or the front page of the manual. This way, we would not discourage casual users while giving the experts something to play with, I'd say.

We should use this concept more often, maybe even generally. From time to time, the idea came to me that we could offer a "simple" site for newbie contributors with reduced complexity, then have them do some onboarding tasks to understand the basics of our data model, and then give them the opportunity to switch to the full expert site.

Just an idea.

[gene]

We should use this concept more often, maybe even generally. From time to time, the idea came to me that we could offer a "simple" site for newbie contributors with reduced complexity, then have them do some onboarding tasks to understand the basics of our data model, and then give them the opportunity to switch to the full expert site.

Just an idea.

I like that idea, too.
Another case where we could use this approach is Game-Titles:

[MZ per X]

Yeah, it is!

(Setup stolen from your post above...)

1) bounded context G: create a Game with working title
2) bounded context TS: create a TransliteratedString ("title")
3) bounded context G: assign the title to the Game *without* regional information
4) bounded context G: create 1...n objects "TitleUsage" underneath the G-TS assignments with region and title type

And later on:
5) bounded context G: assign a title from step 3) to a Release of the game with title location
(Or do you want to split this step up in assignment and title usage as well?)

BTW, why do you also want to assign titles to Release Groups? We don't need it there, I think.

[gene]

I implemented the rule "assign a title usage with a sub-region or parent-region is not allowed".
It is available for testing on https://dev.oregami.org

E.g. assigning another "TitleUsage" for the title "Sony Playstation" (WORLDWIDE has already been assigned) creates an error "REGIONS_NOT_CONSISTENT".
Or try to add a TitleUsage "ASIA" for the ps2 title "プレイステーション" will give an error, because JAPAN has already been assigned.

Next small thing should be removing already assigned TitleUsages.

[MZ per X]

I implemented the rule "assign a title usage with a sub-region or parent-region is not allowed".
It is available for testing on https://dev.oregami.org

Works beautifully, thanks.

[gene]

I implemented the rule "assign a title usage with a sub-region or parent-region is not allowed".
It is available for testing on https://dev.oregami.org

Works beautifully, thanks.

Great!

Meanwhile I translated the existing error messages so that they are not displayed like "DUPLICATE_ENTRY" but instead of as complete sentences.

[gene]

I added a "TitleType" to the TitleUsage.
Check it out on https://dev.oregami.org !

[MZ per X]

I added a "TitleType" to the TitleUsage.
Check it out on https://dev.oregami.org !

Cool stuff, but it seems quite buggy to me in connection with the region validation. Can you test triggering the validation within the "Edit title usage" feature?