CSC/ECE 517 Fall 2010/ch6 6h mf: Difference between revisions
| Line 1: | Line 1: | ||
=Domain Model= | =Domain Model= | ||
The domain model is an [http://en.wikipedia.org/wiki/Object_model object model] that encapsulates the rules, logic, and data associated with the [http://en.wikipedia.org/wiki/Problem_domain problem domain.] The purpose of domain | The domain model is an [http://en.wikipedia.org/wiki/Object_model object model] that encapsulates the rules, logic, and data associated with the [http://en.wikipedia.org/wiki/Problem_domain problem domain.] The purpose of domain modelling is to [http://en.wikipedia.org/wiki/Separation_of_concerns separate the concern] of domain-specific problem solving from other concerns like the user interface and persistent storage. | ||
Domain | A number of different terms are used to refer to the domain model and related concepts. These include Domain Object Model (DOM), domain layer, business layer, business logic, business logic layer (BLL), business tier, and logic tier. Many of these terms are used when describing [http://en.wikipedia.org/wiki/Multitier_architecture multi-tier architectures.] The canonical example is the three-tier architecture composed of the a presentation tier, logic tier, and data tier. The presentation tier is responsible for the user interface. The logic tier (domain model) is responsible for solving problems in the specific domain of the application (often a business domain, hence the term business logic). The data tier is responsible for storing and retrieving information, typically to and from a database. | ||
The three-tier architecture illustrates how domain modelling helps achieve separation of concerns. The presentation tier could be implemented in a number of different ways. For example, it could be a command-line interface (CLI), a graphical user interface (GUI), or a web-based interface. It might be desirable to support several different types of user interfaces. However, the type of interface and its implementation is largely independent from the problem domain. Separating the behaviour and data of the user interface from the behaviour and data of domain model enables developers to reuse domain-specific code while implementing various user interfaces. In addition, weak coupling between the user interface and domain model allows the domain-specific code to vary with negligible effect on the user interface code. | |||
Domain objects represent real world entities, both tangible and intangible, encountered in the problem domain. For example, consider the Spring framework [http://static.springsource.org/docs/petclinic.html PetClinic] sample application. In this application, the domain objects include Person, Vet, Owner, Pet, and Visit. Visit is an example of an intangible entity, in other words an abstract concept, that is part of the problem domain. Contrast these domain objects with GUI objects like buttons and text fields which are not relevant to the problem domain (in this case, operating a veterinary clinic). | |||
Revision as of 19:22, 17 November 2010
Domain Model
The domain model is an object model that encapsulates the rules, logic, and data associated with the problem domain. The purpose of domain modelling is to separate the concern of domain-specific problem solving from other concerns like the user interface and persistent storage.
A number of different terms are used to refer to the domain model and related concepts. These include Domain Object Model (DOM), domain layer, business layer, business logic, business logic layer (BLL), business tier, and logic tier. Many of these terms are used when describing multi-tier architectures. The canonical example is the three-tier architecture composed of the a presentation tier, logic tier, and data tier. The presentation tier is responsible for the user interface. The logic tier (domain model) is responsible for solving problems in the specific domain of the application (often a business domain, hence the term business logic). The data tier is responsible for storing and retrieving information, typically to and from a database.
The three-tier architecture illustrates how domain modelling helps achieve separation of concerns. The presentation tier could be implemented in a number of different ways. For example, it could be a command-line interface (CLI), a graphical user interface (GUI), or a web-based interface. It might be desirable to support several different types of user interfaces. However, the type of interface and its implementation is largely independent from the problem domain. Separating the behaviour and data of the user interface from the behaviour and data of domain model enables developers to reuse domain-specific code while implementing various user interfaces. In addition, weak coupling between the user interface and domain model allows the domain-specific code to vary with negligible effect on the user interface code.
Domain objects represent real world entities, both tangible and intangible, encountered in the problem domain. For example, consider the Spring framework PetClinic sample application. In this application, the domain objects include Person, Vet, Owner, Pet, and Visit. Visit is an example of an intangible entity, in other words an abstract concept, that is part of the problem domain. Contrast these domain objects with GUI objects like buttons and text fields which are not relevant to the problem domain (in this case, operating a veterinary clinic).