Hi,
There is a workaround in EA for creating domains:
1. Create a package for data domains (I created it under my Database Model package).
2. Create tags for DataType, DataTypePrecision and DatatypeSize. Create a "data domain" stereotype for classes.
3. Create a data domain class inheritance tree in the top diagram in your package, with data domains as classes and "data domain" stereotype. For example: primitive domains can be dt_string, dt_number, dt_datetime, dt_boolean...
3. For each primitive type, create a class diagram and populate it with lower-level datatypes (int, float, char, varying, etc.). Assign proper tag values for each datatype class. For example, dt_money would have DataType = FLOAT, DataTypePrecision = 2, DataTypeSize = 15 (or whatever values you preffer). I would suggest that DataType have the ANSI data types as the valid types.
5. Add each non-abstract data type as a database data type (Settings -> Database data types...). This will make them visible and usable for your tables. In other words, intead of using the RDBMS datatypes, use your own dt_s
6. For RDBMSs that support data domains (SQL Server, PostGreSQL...) generate your data types with the code generation templates: at the Class Body level (be sure that the upper levels call Class Body), create a Stereotype Override for "data domain". In that template, you can create an "if" cascade to transform your ANSI types to your databases' data types:
%if classTag:"DataType" == "FLOAT"%
$dt = "NUMERIC"
%elseIf...%
And at the end just make the code to create your user defined datatype. For instance:
IF (
SELECT COUNT(*)
FROM systypes WHERE name = '%className%'
) > 0 EXEC sp_droptype '%className%'
EXEC sp_addtype %className%,$dt
GO
7. You can generate your domains (Ctrl + G) either into individual files, or into a sigle file, and run it in your RDBMS.
The above procedure can take some time, especially if you have not defined your domain tree. However, it is quite worthwhile if you are using EA (or are planning to use EA) in several projects, and you recognize the usefulness of data domains. It can also make your models (or model elements) transportable from one RDBMS to another, without having to change datatypes ("the forest guard ain't gonna like that, Yogi..").
I have been using this approach for about three years now, and it has been enormously useful. I have found a problem, however, and it has to do with the fact that Oracle does not suppor ANSI data domains: you can create user-defined types in Oracle, but these are not what you would expect. It would take me a long time to explain it, but the heart of the matter is that the datatype generation approach does not work for Oracle. So what I have to do to transport reusable model elements into Oracle is to use a multi-change routine (outside EA) that transforms dt_int into NUMBER(10), dt_weight into NUMBER(8,5), dt_address into VARCHAR2(70)...
Hope this helps, but please take into account that there is a Code Generation Template learning curve involved.
Jaime