View source for AWG Domain rationale discussion

'''This is intended to explain, in some detail, the basis for the definition offered in the glossary. Please feel free to add to it, ask questions, and generally help articulate this more clearly'''

[[Architecture Working Group Glossary|Glossary#Domain]]

In normal usage, within computer architecture, a domain is a span of authority or trust, or in the case of DNS, a subtree of name space. Linden has proposed splitting the current flat system into an agent domain, and a region domain, and then, multiple agent and region domains. (in the 2008 picture, we see SecondLife Agents, XYZ Employees, XYZ land, and LindenMainland, as examples of domains, as well as a third domain, marked as central utilities. This strongly implies that domains which are both functional as well as trust/authority based. 

Pragmatically, domains are only useful, if they give us some leverage in building the system. In other words, when we separate a set of components into a domain, we should expect to gain some technical leverage from the distinction. Grouping services by trust, for example permits us to use lower cost mechanisms to establish trust between services in the domain. Grouping services by function, seems less obvious, unless there is a very specific load balancing benefit from the grouping. (There may be perfectly good reasons for a company hosting a service to group servers by function for administrative purposes, but.. that probably is nicely out of scope for an architectural distinction) 

So... abstractly, a domain is a grouping of resources which have some properties in common, such that we can use those properties when structuring the system, on an architectural level. 

[[Category:Architecture Working Group]]
[[Category:AWGroupies]]