When embarking on a software project, one should focus on the domain it is operating in . Therefore, the domain modelling process should be standardized in a way that any business domain could be modelled by any project architect in any development environment in the same way. The idea of software components servicing other software components in a cooperative environment is a long established approach to software design. Web Services, today, is a technological asset that is revitalizing the design of enterprise architectures by enabling the orchestration of different business contexts .
Also, in  we understand that “…SOA means that we don’t have to build applications any more – all we have to do is invoke other people’s services.” Thus, service implementation is merely a collection of service invocations, and the services invoked are implemented by other service invocations, and so on, ad infinitum. Basically a business domain should be represented by a set of cooperative business services, either local or remote, while services consist of a set of software components, either local or remote.
Within this context, we have established a standard Service-Oriented Architecture to model business domains for projects conducted in public organizations. As figure 2 presents, the SOA BUS is used to orchestrate different business services, representing a valuable strategy to integrate older and proprietary platforms. By standardizing the orchestration process it is possible to deliver flexible architectures capable to respond to changes in an affordable manner .
The next topics detail how the project architect should design domain models in such a way that it could be reused by different development teams.
Domain-Driven Development Conception
Our primary goal was to create a development environment in which architects could reuse domain models in different projects. Throughout ongoing projects, MDA was already being systematically used in software development. The process was similar in every project and both software architecture and coding produced the same software artefacts due to the standardization of tools and analysis processes. By creating an unified domain modelling process, we were able to broaden our abstraction perspective and share generic business concepts across different public organizations. To come up with useful domain artefacts we needed to create a domain representation that would indicate the services or components that should be included in the domain model, and that should be used for implementation by the MDA tool. For that purpose we followed a five-step design process, in order to enable domain-driven development:
1. Business Domain-Modelling. This stage was responsible for identifying the services and software components the domain required. Our goal was to create an infrastructure that could cope with any service or component ever modelled in any project.
2. Creating the XMI file. This stage came up with a modelling style that used the XMI format to design the domain. The XMI file aggregates domain information including local services and component model files as well as URL links to remote files and storage locations.
3. Storing Domain Services and Component models. The third stage implied in storing the models created by project architects in accessible databases. Each project should have its own database and expose their content through a Web service.
4. Exposing and Sharing Domain Models. This stage relates to publishing the models in project Web services. Every project should have its own Web service in order to allow other projects to access domain information as well as services and component models.
5. Automate Code Generation. This stage uses the domain models to generate software code. According to that point, specific business rules might be modelled and incorporated in the final product.