第1页 Preface - Default Paths and File Names

domain-root-dir: Represents the directory in which a domain is created by default.
default value: as-install/domains/

domain-dir: Represents the directory in which a domain’s configuration is stored. In configuration files, domain-dir is represented as follows: ${com.sun.aas.instanceRoot}
default value: domain-root-dir/domain-name
Concept of a GlassFish Domain ...
https://blogs.oracle.com/bloggerkedar/entry/concept_of_a_glassfish_domain

GlassFish has a concept of a domain. More precisely, it is the administrative domain. At first, it may be perceived a little difficult to understand, especially given that in Java EE paradigm, one is used to servers rather than domains. This is especially true with developers. 
This post tries to explain what a GlassFish Domain (domain, henceforth) is, how to use it effectively if you want to quickly deploy your applications to GlassFish and the reasons to call it a domain.

A domain (statically) is an administrative name space. It's a boundary, all GlassFish entities within which are controlled by an administrator or more precisely administrative three tuple (Let's call it Admin 3T). This three tuple is called "admin user, admin password, certificate database password (or master password). If you are a developer, you don't really care about the master password and it defaults to "changeit". This is the password with which your keystore (cacerts.jks) is locked and most of the times, you don't care about this.

This is how your domains look like.
 

A domain (dynamically) is a Java EE Engine. Thus it is your server, once you have started it. In other words, at run time, a domain = server. Thus, a running domain can host user Java EE applications and can be effectively used as the target for your deployments. For developers, this is what they care about. It is for developers that this gap has been bridged and they can forget about the domain. The defaults are so carefully chosen that you'd never need to know about the fact that you are managing and deploying to a domain!

So, what is that that domain provides on top of behaving like a server? Here is a list of things:

1) Domain provides you with a built-in administration capability.
2) Domain has multiple system applications predeployed which facilitate the management. Thus the entire admin console is available as a system web application. All you need to do it connect to "http://localhost:admin-port(4848)".
3) Domain has another system application predeployed to take care of all the asadmin commands. Note that (almost) all the asadmin commands invoke the running domain in.
4) Domain has an EJB Timer Service already configured to work with. A timer database is also created.
4) Domain has a JDBC Connection Pool configured for the EJB timer database.
5) Domain has two keyfiles created by default so that one has authentication realms for the security conscious people. All you need to do is create the security mappings in your applications.
6) Domain has a default web.xml that decides the default behavior of all deployed web applications.
7) Domain has a JMX Connector's Server end so that you can easily connect to the admin infrastructure, using JConsole and browse the MBeans. As you know MBeans are to Administration what EJB's are to Enterprise Computing.

All this is enabled by a simple set of steps:

1. Either you download GlassFish and invoke ant -f setup.xml that creates the so-called fully configured, ready-to-go default domain, OR
2. Explode the GlassFish image and do [glassfish]/bin/asadmin create-domain --adminport 4848 mydomain

All this is great. But how does a developer exploit it?

Simple. Your answer is NetBeans. Just download "The" IDE and do the following:

1. Go to the Runtime tab and right click for "Adding a target server". 
See how NetBeans itentifies your default domain, domain1. The port is also identified. This is the administration port. Next, you could provide the user name and password for administration. That's it. This domain is now deployment ready .
2. You need to create a web application. Just create it using the intuitive menus in the IDE. 
3. The IDE is so well integrated with the GlassFish domain/server is that it just allows you to start the GlassFish server in debug mode and debug your application. This is really seamless!
Here is your application deployed and being tested! 
This is how I develop and test my applications. I am a developer. Hope fellow developers find this as easy as I do. 

If you are a CLI fan, there are a bunch of intuitive asadmin commands that configure the domain/server. 
If you are an ANT fan, there are ANT tasks like sun-appserv-deploy that help you continue to write your build.xml files. 
We are planning to integrate asadmin into a scripting language of your choice. You'd have to wait till Mustang releases, though. 
I know this sounds easy. But it sounds so because it is so. 

Finally, the $1M Question: Why do you call it a domain? Well, the reason lies in more sophisticated Sun Software like Application Server Standard Edition (SE) . When you enter into the real enterprise arena, it is no more a server. It is a bunch of servers (which are also known as app server instances, each of which is a Java EE Engine) that are woven into clusters to impart the coveted high availability. Still, the "Administrative" domain remains the same. You don't have to learn a new concept when you go from one edition of the product to an advanced one. A set of simple rules emerges:

1) A Domain is comprised of a set of Instances. A Domain is "bigger" than an Instance.
2) Domain has a "dual nature". For a simple case, Domain equals Instance (I tend to relate to the dual nature of electron -- "is it a wave, is it a particle" here  ). 

Thus, it is the best of both the worlds: For developers, a domain is a server. For system administrators, a domain is something that they manage so that an uninterrupted service is provided! 

Makes sense to me. How about you? Please let me know ...