Domain Based Attribute best use

Question

Hello,

I am currently working on implementing a MDS solution and I have trouble figuring out a way of modeling some of our data due to a lot of shared structures between our entities. For example, we have entities for Our B2C Customers, B2B Customers, Suppliers that share a lot of attributes.

For example, someone/a company address in our systems is a set of 4 or 5 attributes (always the sames attributes) and I am wondering on the best way to model this in MDS. 

From what I can see I can either :

- Duplicate all theses attributes in the all the entities. The problem with this solution is that I don't know a way to indicate that these duplicated attributes relate to the same kind of data ?

- Regroup these attributes in an Entity and use it as a domain attribute for my different "real" entities. However I read somewhere that domain attribute should be used to restrict the user choice on an attribute so I am not sure that I am using the paradigm as I should. Furthermore when a user will edit a member from the excel add-in for example, he won't be able to directly edit the set of attribute.

Is there any guidelines on the best way to model this ?  

Someone asked this same question a while ago on this forum but did not get any answer...

Regards

Answer 1

Hello,

This is a good modelling question, and like all modelling questions, it is quite tricky to answer without knowing the data and business involved.

Personally, I'll prefer to use domain entities over collections. In your example, and with very limited knowledge, I will create the following entitties:

• Customer Type -  B2C, B2B ....
• Customer - including a Customer Type domain attribute, and all the address fields
• Supplier - including the address fields
• One or more geography entities covering countries, country divisions and subdivisions, and localities (covering at least major cities and towns). The complexity of your geography entities depends, in my opinion, on how many countries your business covers. Both the Customer and Supplier entities should include domain attributes referring to the geography entities
• Depending on how strict you need/want to be, you can extend the model further and have a Post Code entity underpinning your address entry. But this is worth it, in my opinion, only if you have a database of postcodes and addresses.

Hope this helps.

Kind regards,

M 

Answer 2

Well thank you for answering,

It is true that it is difficult to answer without knowing the data and business related, but the answer you gave confirm the way I understood the way Domain attribute should be used, i.e. as holders of non-mutable data.

Regards,

Answer 3

You are welcome.

You are always going to have some mutability in the data, the key thing is that the mutability is slow. In other words, you are likely to have customers changing addresses but not every week.

Handling data mutability -  changing data - in MDS is slightly tricky because the member code is unique (per version, I think).

One thing that I would add to the previous message is that if you have many suppliers which are also customers, you might want to merge the Customers and Suppliers entities and add an additional type ('Supplier Type'). But if your Suppliers and Customers are 2 separate sets of data with little or without overlapping, then, in my opinion, you should keep them separate.

Regards,