Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch5 5e mf

2010-11-23T03:10:24Z

Mafashin: /* References */

=The Dependency Injection Pattern=

==An explanation by way of example==

The [http://martinfowler.com/articles/injection.html#FormsOfDependencyInjection dependency injection] pattern is a design pattern for fully decoupling a class from the creation of other classes upon which it depends. In this sense, it is similar to the [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2009/wiki3_6_Factory_Design_Pattern factory] and [http://martinfowler.com/articles/injection.html#UsingAServiceLocator service locator] patterns which are also concerned with abstracting object creation away from the dependent class. The utility of and differences between these patterns is subtle and difficult to explain without a lot of jargon. So the concepts will be demonstrated through example. Suppose, that Syd has a [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch3_3h_az strategy] for making statements about objects illustrated in the following Ruby code.
<pre>
# A strategy for remarking on things.
class Syd
def remark
if @thing.got_it?
puts "I've got a #{@thing}."
else
puts "I know a #{@thing}."
end
end
end
</pre>

With this method, Syd can make a statement about any object thing that implements the methods got_it? and to_s. The Bike class shown below is an example.
<pre>
# An example of a thing upon which to remark.
class Bike
def to_s
"bike"
end
def got_it?
return true
end
end
</pre>

===Direct instantiation===

In order for Syd to use his strategy, he must get ahold of a thing. The simplest way to do this is to instantiate a thing directly.
<pre>
# An example of direct object instantiation.
class Syd
def initialize
@thing = Bike.new
end
end
</pre>

However, now all that Syd can talk about is his bike. This is because, although Syd has a strategy for talking about a wide variety of things, Syd depends on the concrete class Bike for thing creation.

===The factory pattern===

A common technique for encapsulating object instantiation is the factory pattern. The following example uses a factory to allow Syd to talk about an array of things. In this case, thing creation is random, but a more complex factory might be configurable through constructor arguments or some external resource like an XML file.
<pre>
# An example of the factory pattern.
class ThingFactory
def initialize
# An array of thing classes.
@things = [Bike, Cloak, Mouse, GingerbreadMen, Room]
end
def create_random_thing
# Pick a random thing and create an instance of it.
@things.sort_by { rand }[0].new
end
end

$thing_factory = ThingFactory.new

class Syd
def initialize
# Use the factory to create a random thing
@thing = $thing_factory.create_random_thing
end
end
</pre>

One major drawback of using the factory pattern is that each abstraction needs its own factory. In this case, the only abstraction is thing, but if there were many abstractions this could lead to a lot of unnecessary code duplication, since factories are often similar to one another. This may result in code that is difficult to maintain. Consider the case where object instantiation is configured by some outside resource like an XML file. If each factory must independently obtain information from this resource, then every time that the format of the XML file changes, every factory implementation must be modified as well.

===The service locator pattern===

The service locator pattern addresses the problem of factory proliferation by centralizing object instantiation. In a sense, the service locator consolidates a collection of factories into a single repository from which other objects may request dependencies. However, the role of the service locator is somewhat different from the factory. Whereas factories are specifically concerned with object [http://en.wikipedia.org/wiki/Creational_pattern creation,] the service locator is concerned with supplying dependencies to objects. Consider several classes which all depend on a common abstraction. Whereas a factory would typically create an instance of the abstraction for each of the classes, the service locator might create a single instance and supply it to all of the classes.

The example problem is not complex enough to truly benefit from a service locator, but the following example code demonstrates how a service locator can facilitate code reuse. The class_eval method is used to add methods procedurally for each of the abstractions ("services") that the service locator provides. If the method of random object creation needs to be modified at some point in the future, there is only a single definition that needs to be changed.
<pre>
# An example of the service locator pattern.
class ServiceLocator
def initialize
# Several arrays of abstractions
@things = [Bike, Cloak, Mouse, GingerbreadMen, Room]
@charms = [Heart, Star, Horseshoe, Clover]
@triffles = [Tiramisu, StrawberryShortcake, TipsyLaird]
end
end
# Add a get_random method for each abstraction
[:thing, :charm, :trifle].each do |abstraction|
ServiceLocator.class_eval "def get_random_#{abstraction}
@#{abstraction}s.sort_by { rand }[0].new
end"
end

$service_locator = ServiceLocator.new

class Syd
def initialize
# Use the service locator to get a random thing
@thing = $service_locator.get_random_thing
end
end
</pre>

However, the factory and service locator patterns share a common disadvantage. Namely, a class which uses a factory or a service locator necessarily depends on the factory or service locator. This has potentially serious implications for code maintainability. A class which uses a service locator must know the name and calling conventions of the service locator in order to use it. If the name or calling conventions of the service locator are modified, all classes which use the service locator must also be modified. The same is true of factories.

===The dependency injection pattern===

Dependency injection eliminates the dependency between a class and the mechanism used to supply its dependencies. Rather than make an object responsible for acquiring its own dependencies (directly, through factories, or through a service locator), dependency injection places the responsibility on the code that uses the object to provide the dependencies that the object needs. This is usually accomplished either by passing dependencies as arguments to the object's constructor or to a setter method. The following code example accepts both forms of dependency injection.
<pre>
# An example of the dependency injection pattern.
class Syd
attr_writer :thing
def initialize(thing)
# Constructor injection.
@thing = thing
end
end
</pre>

Dependency injection is an example of the [http://martinfowler.com/bliki/InversionOfControl.html inversion of control] principle. Rather than giving a class control of the creation of its own dependencies, control is abstracted out to higher-level code (an "assembler") which creates the dependencies and provides them to the class.

This method of decoupling a class from its dependencies makes the dependency injection pattern fundamentally different from the factory and service locator patterns. Whereas the factory and service locator patterns encapsulate object instantiation so as to hide the concrete class from the dependent object, the dependency injection pattern pulls the act of object instantiation outside of the dependent object through inversion of control.

==Dependency injection and duck typing==

It is worth noting that the example code for the dependency injection pattern is much simpler than for the factory and service locator patterns. This is partly because the logic of object instantiation has been pulled outside the example, but it is also because dependency injection fits in well in [http://en.wikipedia.org/wiki/Duck_typing duck-typed] languages like Ruby.

Duck typing means that any object may be passed as an argument to a method and, so long as it possesses the necessary methods and attributes, the program will execute properly. In the previous code example, there is no interface or abstract base class from which objects inherit. Any object which implements the got_it? and to_s methods may be used as a thing. This makes it easy to create new classes and modify existing classes to be used as things.

Dependency injection complements duck typing nicely, because any object with the methods necessary to meet the needs of the dependent class may be injected. Objects which were never explicitly designed to satisfy a dependency can be used to meet it with little or no modification. In contrast, a factory or service locator would have to be modified to support supplying the new class of object.

==Real applications of dependency injection==

===Software frameworks===

Dependency injection is a key feature of many software frameworks. [http://www.springsource.org/ Spring] is a notable example. A software framework is essentially an application skeleton with a well-specified application programming interface (API) intended to serve as an extensible base for developing a fully-fleshed out application. Since library methods are called by an application, the application controls the flow of execution. This means that typically a significant amount of an application developed using libraries must be implemented before the application will be capable of doing anything useful.

In contrast, a software framework is already a functional piece of software before the application developers writes any code. Application developers override or specialize parts of the framework in order to extend its functionality. This is possible because frameworks follow the design principle of inversion of control. Rather than allow the application code to dictate the path of execution, the framework controls it.

Since software frameworks employ inversion of control, dependency injection is a natural fit. If a framework specifies an appropriate set of conventions to application developers, the framework can infer the dependencies of application code and inject them into it. Which classes the framework will use to fulfill the application dependencies and how it will initialize them is typically controllable through some form of configuration file. However, many frameworks follow a [http://en.wikipedia.org/wiki/Convention_over_configuration convention over configuration] philosophy and will infer parameters which are not specified by the developer.

===PicoContainer===

[http://www.picocontainer.org/ PicoContainer] is another example of a real world application of dependency injection. PicoContainer provides a container class to which one may add arbitrary Java classes. If the constructors of some of these classes depend on interfaces implemented by other classes, PicoContainer will infer these dependencies and use instantiations of objects which implement the required interfaces in order to instantiate other objects. Consider the following example code take from the [http://www.picocontainer.org/introduction.html PicoContainer website.]
<pre>
# Source: http://www.picocontainer.org/introduction.html

public interface Peelable {
void peel();
}

public class Apple implements Peelable {
public void peel() {
}
}

public class Peeler implements Startable {
private final Peelable peelable;

public Peeler(Peelable peelable) {
this.peelable = peelable;
}

public void start() {
peelable.peel();
}

public void stop() {
}
}

public class Juicer {
private final Peelable peelable;
private final Peeler peeler;

public Juicer(Peelable peelable, Peeler peeler) {
this.peelable = peelable;
this.peeler = peeler;
}
}
</pre>

The classes given above may be added to an instance of PicoContainer.
<pre>
# Source: http://www.picocontainer.org/introduction.html

MutablePicoContainer pico = new DefaultPicoContainer();
pico.addComponent(Apple.class);
pico.addComponent(Juicer.class);
pico.addComponent(Peeler.class);
</pre>

PicoContainer infers how to instantiate these classes from their constructors. The instantiations may then be retrieved from the PicoContainer.
<pre>
# Source: http://www.picocontainer.org/introduction.html

Juicer juicer = (Juicer) pico.getComponent(Juicer.class);
</pre>

The class definitions given above are interdependent and these dependencies may be satisfied through construction injection. By requiring developers to write classes which follow this relatively simple convention (constructor injection of interfaces), PicoContainer is able to resolve the dependencies automatically for the developer. Under the hood, PicoContainer is doing something roughly like the following code.
<pre>
# Source: http://www.picocontainer.org/introduction.html

Peelable peelable = new Apple();
Peeler peeler = new Peeler(peelable);
Juicer juicer = new Juicer(peelable, peeler);
return juicer;
</pre>

This process would be much more complicated if not impossible using the factory or service locator pattern, since the class dependencies would be hidden inside the classes rather than exposed in their constructors.

==References==

<ul>
<li>FOWLER, M. 2004. [http://martinfowler.com/articles/injection.html Inversion of control containers and the dependency injection pattern.] In ''Martin Fowler's Bliki.''
</li>
<li>FOWLER, M. 2005. [http://martinfowler.com/bliki/InversionOfControl.html Inversion of control.] In ''Martin Fowler's Bliki.''
</li>
<li>HELLESOY, A., AND TIRSEN, J. [http://www.picocontainer.org/introduction.html PicoContainer introduction.] In ''PicoContainer.''
</li>
<li>JOHNSON, R., ET AL. 2010. [http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/ Spring framework: reference documentation.] In ''SpringSource.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch5 5e mf

2010-11-23T02:58:55Z

Mafashin:

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:54:37Z

Mafashin: /* Conclusion */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx "The mythical business layer."]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (a TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer which returns true if they are authorized to issue a CancellationRequest and false if they are not. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==Conclusion==

Domain modelling is a useful technique for separating problem domain-specific concerns from concerns which are unrelated to the problem domain, like user interfaces and databases. Developing a good domain model requires a thorough understanding of what is and what is not part of the problem domain. Good candidates for inclusion in a domain model are real-world entities related to the problem the software solves, the relationships between those entities, and the behaviours and data associated with those entities.

A good domain model is only weakly-coupled with other parts of an application. This allows domain-specific logic and entities to vary without affecting other system components and vice versa. However, a good domain model is still cohesive. Separating responsibilities from domain objects unnecessarily produces the anemic domain model anti-pattern in which service objects are tightly-coupled with domain objects and domain objects lack cohesion.

==References==

<ul>
<li>AMBLER, S. 2010. [http://www.agiledata.org/essays/agileDataModeling.html Agile/evolutionary data modeling: from domain modeling to physical modeling.] In ''Agile Data.''
</li>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:53:51Z

Mafashin: /* Conclusion */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx "The mythical business layer."]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (a TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer which returns true if they are authorized to issue a CancellationRequest and false if they are not. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==Conclusion==

Domain modelling is a useful technique for separating problem domain-specific concerns from concerns which are unrelated to the problem domain, like user interfaces and databases. Developing a good domain model requires a thorough understanding of what is and what is not part of the problem domain. Good candidates for inclusion in a domain model are real-world entities related to the problem the software solves, the relationships between those entities, and the behaviours and data associated with those entities.

A good domain model is only weakly-coupled with other parts of an application. This allows domain-specific logic to vary without affecting other system components and vice versa. However, a good domain model is still cohesive. Separating responsibilities from domain objects unnecessarily produces the anemic domain model anti-pattern in which service objects are tightly-coupled with domain objects and domain objects lack cohesion.

==References==

<ul>
<li>AMBLER, S. 2010. [http://www.agiledata.org/essays/agileDataModeling.html Agile/evolutionary data modeling: from domain modeling to physical modeling.] In ''Agile Data.''
</li>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:43:18Z

Mafashin:

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx "The mythical business layer."]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (a TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer which returns true if they are authorized to issue a CancellationRequest and false if they are not. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==Conclusion==

Domain modelling is a useful technique for separating problem domain-specific concerns from concerns which are unrelated to the problem domain, like user interfaces and databases. Developing a good domain model requires a thorough understanding of what is and what is not part of the problem domain. As such, a good domain model is only weakly-coupled with other parts of an application. This allows domain-specific logic to vary without affecting other system components and vice versa.

==References==

<ul>
<li>AMBLER, S. 2010. [http://www.agiledata.org/essays/agileDataModeling.html Agile/evolutionary data modeling: from domain modeling to physical modeling.] In ''Agile Data.''
</li>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:32:31Z

Mafashin: /* Anemic domain models */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx "The mythical business layer."]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (a TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer which returns true if they are authorized to issue a CancellationRequest and false if they are not. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

<ul>
<li>AMBLER, S. 2010. [http://www.agiledata.org/essays/agileDataModeling.html Agile/evolutionary data modeling: from domain modeling to physical modeling.] In ''Agile Data.''
</li>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:29:49Z

Mafashin: /* An example of business logic */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx "The mythical business layer."]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (a TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

<ul>
<li>AMBLER, S. 2010. [http://www.agiledata.org/essays/agileDataModeling.html Agile/evolutionary data modeling: from domain modeling to physical modeling.] In ''Agile Data.''
</li>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:27:42Z

Mafashin: /* References */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx "The mythical business layer."]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

<ul>
<li>AMBLER, S. 2010. [http://www.agiledata.org/essays/agileDataModeling.html Agile/evolutionary data modeling: from domain modeling to physical modeling.] In ''Agile Data.''
</li>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:05:01Z

Mafashin: /* An example of business logic */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx "The mythical business layer."]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

<ul>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:04:17Z

Mafashin: /* Anemic domain models */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html anemic domain model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

<ul>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-18T00:03:57Z

Mafashin: /* References */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

<ul>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] In ''TechnoGeek.''
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>FOWLER, M. 2003. [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic domain model.] In ''Martin Fowler's Bliki.''
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
<li>PAPADIMOULIS, A. 2007. [http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The mythical business layer.] In ''The Daily WTF.''
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:58:47Z

Mafashin: /* References */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

<ul>
<li>CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] TechnoGeek.
</li>
<li>FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.
</li>
<li>OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.
</li>
</ul>

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:55:03Z

Mafashin: /* References */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

CHIN, P.-T. 2008. [http://www.hostfrontier.com/index.php/200811029/agile-methodology/domain-modelling-using-color-uml.html Domain modelling using color UML.] TechnoGeek.



FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.



OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:52:03Z

Mafashin: /* References */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.



OLDFIELD, P. 2002. [http://www.aptprocess.com/whitepapers/DomainModelling.pdf Domain modelling.] White paper, Mentors of Cally Ltd.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:45:40Z

Mafashin: /* Domain Models */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

==References==

FOWLER, M. 2002. ''Patterns of Enterprise Application Architecture.'' Addison-Wesley Professional.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:39:54Z

Mafashin: /* An example of business logic */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model. Understanding which issues are specific and relevant to the problem domain and which are not is essential to developing a good domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:37:20Z

Mafashin: /* Introduction */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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 principle advantage of domain modelling is that it [http://en.wikipedia.org/wiki/Separation_of_concerns separates 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 [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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:32:50Z

Mafashin: /* Introduction */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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.

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.

Understanding the problem domain is critical to developing a good domain model. Well-designed software should exist to solve a problem. The problem domain encompasses all the entities, relationships, data, rules, and logic that are necessary to solve the problem. Conversely, entities, relationships, data, rules, and logic which are not necessary to solve the problem are outside the problem domain.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:22:44Z

Mafashin: /* Anemic Domain Models */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

==Anemic domain models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:21:37Z

Mafashin: /* Anemic Domain Models */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

==Anemic Domain Models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the domain object-specific logic in the domain model. One way to accomplish this and still use the service object above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:19:12Z

Mafashin: /* Anemic Domain Models */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

==Anemic Domain Models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

A better design keeps the business logic in the domain model. One way to accomplish this and still use the service object introduced above is to add a mayIssueCancellationRequests() method to domain objects which may be passed to a CancellationRequestIssuer. This allows domain objects to encapsulate their own specific business logic, while allowing CancellationRequestIssuer to generalize the actual issuance of a CancellationRequest.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:15:37Z

Mafashin: /* Anemic Domain Models */

=Domain Models=

==Introduction==

The [http://en.wikipedia.org/wiki/Domain_model 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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

==Anemic Domain Models==

When domain models fail to encapsulate behavior as well as entities and data, the [http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model] [http://en.wikipedia.org/wiki/Anti-pattern anti-pattern] results. One symptom is the presence of a [http://martinfowler.com/eaaCatalog/serviceLayer.html service layer] which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. However, the domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.

For example, consider the business logic example given above. One could create a service object CancellationRequestIssuer like the one diagrammed below.

{| border="1"
| '''CancellationRequestIssuer'''
|-
| 
|-
| issue(employee : Manager, item : TransferableReceivable) : CancellationRequest issue(employee : Executive, item : TransferableReceivable) : CancellationRequest
|}

This may seem like a reasonable way to avoid code duplication, since presumably a CancellationRequest issued by a Manager will be more or less identical to one issued by an Executive. However, there is an additional bit of logic in the domain model for a Manager which this design pushes into the service layer. Namely, before allowing a Manager to issue a Cancellation request, the application must check that the Manager attribute hasVoidApproval equals true.

Putting this logic in CancellationRequestIssuer violates the encapsulation of hasVoidApproval within Manager. In addition, stripping this logic out of Manager reduces [http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 cohesion.] Furthermore, with this design, CancellationRequestIssuer is responsible for assuring that all domain objects which may issue a CancellationRequest are authorized to do so. This means that CancellationRequestIssuer is tightly-coupled with these domain objects (in the sense that it needs information encapsulated within them to authorize requests).

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T23:02:52Z

Mafashin:

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:55:02Z

Mafashin: /* Anemic Domain Models */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:51:24Z

Mafashin: /* Anemic Domain Models */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:49:36Z

Mafashin: /* Anemic Domain Models */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:49:13Z

Mafashin: /* Anemic Domain Models */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:48:52Z

Mafashin: /* Anemic Domain Models */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:27:16Z

Mafashin: /* An example of business logic */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:25:06Z

Mafashin: /* An example of business logic */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:24:21Z

Mafashin: /* Introduction */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:23:22Z

Mafashin: /* An example of business logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Relationships are not represented. Sale has a one-to-many has-a relationship with TransferableReceivable (an item that is included in the sale). It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:17:05Z

Mafashin: /* An example of business logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." The domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Class diagrams for the domain objects are presented in UML below. Relationships are not represented. Sale has a one-to-many has-a relationship with TransferableReceivable (an item that is included in the sale). It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
| 
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
| item : TransferableReceivable
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
| 
|}

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:15:00Z

Mafashin: /* Business Logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==An example of business logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." The domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Class diagrams for the domain objects are presented in UML below. Relationships are not represented. Sale has a one-to-many has-a relationship with TransferableReceivable (an item that is included in the sale). It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
|
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
|
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
|
|}

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:14:40Z

Mafashin: /* Business Logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==Business Logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." The domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Class diagrams for the domain objects are presented in UML below. Relationships are not represented. Sale has a one-to-many has-a relationship with TransferableReceivable (an item that is included in the sale). It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
|
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
|
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
|
|}

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T22:03:53Z

Mafashin: /* Business Logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==Business Logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." The domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

{| border="1"
| '''Sale'''
|-
| items : TransferableReceivable[]
|-
| clear()
|}

 

{| border="1"
| '''Manager'''
|-
| hasVoidApproval : Boolean
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''Executive'''
|-
|
|-
| issueACancellationRequest(item : TransferableReceivable) : CancellationRequest
|}

 

{| border="1"
| '''CancellationRequest'''
|-
|
|-
| issueForProcessing() issueForApproval()
|}

 

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus : Enum expenseAllocationType : Enum
|-
|
|}

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T21:42:41Z

Mafashin: /* Business Logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==Business Logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances under which a sale may be cancelled. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." The domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

{| border="1"
| '''Sale'''
|-
|
|-
| clear() : TransferableReceivable
|}

{| border="1"
| '''Manager'''
|-
| hasVoidApproval
|-
| issueACancellationRequest(sale : Sale) : CancellationRequest
|}

{| border="1"
| '''Executive'''
|-
|
|-
| issueACancellationRequest(sale : Sale) : CancellationRequest
|}

{| border="1"
| '''CancellationRequest'''
|-
|
|-
| issueForProcessing()
| issueForApproval()
|}

{| border="1"
| '''TransferableReceivable'''
|-
| propagationStatus expenseAllocationType
|-
|
|}

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T21:16:15Z

Mafashin: /* Business Logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==Business Logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

This example dictates the circumstances under which a sale may be cancelled. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." The domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is IssueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T21:10:27Z

Mafashin: /* Business Logic */

=Domain Models=

==Introduction==

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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

==Business Logic==

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that might be representing in a domain model appears in
[http://thedailywtf.com/Articles/The-Mythical-Business-Layer.aspx The Mythical Business Layer.]
<blockquote>
''When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.''
</blockquote>

In this example, the domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a rule is that "only Managers with Void Approval... may issue a Cancellation Request."

==Anemic Domain Models==

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T20:47:09Z

Mafashin: /* Introduction */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T20:46:16Z

Mafashin: /* Domain Model */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T19:57:20Z

Mafashin: /* 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 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.

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, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. 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).

[[Image:Pet_clinic_uml.png]]

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person does not even appear in the PetClinic database.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T19:52:14Z

Mafashin: /* Domain Model */

File:Pet clinic uml.png

2010-11-17T19:48:05Z

Mafashin: A simple UML representation of the domain model from the Spring Framework [http://static.springsource.org/docs/petclinic.html PetClinic] sample application.

A simple UML representation of the domain model from the Spring Framework [http://static.springsource.org/docs/petclinic.html PetClinic] sample application.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T19:32:26Z

Mafashin: /* 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 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.

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, which is a simple example of a three-tier architecture. 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).

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an [http://en.wikipedia.org/wiki/Is-a is-a] relationship with a Person and a [http://en.wikipedia.org/wiki/Has-a has-a] relationship with a Pet.

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T19:27:54Z

Mafashin: /* 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 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.

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, which is a simple example of a three-tier architecture. 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).

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T19:22:04Z

Mafashin: /* 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 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.

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).

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T18:03:29Z

Mafashin: /* Domain Model */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T17:55:47Z

Mafashin: /* Domain Model */

CSC/ECE 517 Fall 2010/ch6 6h mf

2010-11-17T17:46:21Z

Mafashin: