Domain Driven Design: Use Case Template

 

 

          Informal Use Case

Patron Loses a Book The library patron reports to the librarian that she has lost a book. The lost a book. The librarian librarian prints out the library record prints out the library record and asks patron to speak with the head librarian, who will arrange for the patron to pay a fee. The system will be updated to refl

Technorati Tags: DDD,use case template,domain driven design

ect lost book, and patron be updated to reflect lost book, and patron s' record is record is updated as well. The head librarian may authorize purchase of a replacement tape.

Formal Use Case

1	GOAL	Patron wishes to reserve a book using the online catalog
2	Primary Actor	Patron
3	Scope	Library system
4.	Level	User
5.	Pre Conditions	Patron is at the login screen
6.	Success end Conditions	Book is reserved
7.	Failure End Conditions	Book is not reserved
8.	Triggers	Patron logs into system
9.	Main Success Scenario	1. Patron enters account and password Scenario 2. System verifies and logs patron in System verifies and logs patron in 3. System presents catalog with search screen 4. Patron enters book title 5.  System finds match and presents location choices to patron 6. Patron selects location and reserves book 7. System confirms reservation and re-presents catalog
10.	Extensions ( error scenarios)	2a. Password is incorrect (error scenarios)          2a.1 System returns patron to login screen          2a.2 Patron backs out or tries again
11.	Variations	Patron enters author or subject

 

Steps in creating a use case

1. Identify actors and their goals

        What computers subsystems and people will drive our computers, subsystems and people will drive our system?

          (actors)

 

2. What does each actor need our system to do ?

       (goals )

           3. Write the success scenario

                         – easiest to read and understand

            – everything else is a complication on this

Capture each actor's intent and responsibility, from trigger to goal delivery

                  – say what information passes between them say what information passes between them

                  – number each line

              4. List the failure extensions

              5. List the variations               

 Use case description

1. How and when it begins and ends

2. The interactions between the use case and its actors, including including when the interaction interaction occurs and what is exchanged .

3. How and when the use case will need data from or store data to the system .

4. How and when concepts of the problem domain are handled

Differences between Entities and Value Object.

1.

When you have two Entities with the same attributes, these two objects are not the same because they have two different identities.

However, when you have two Value Objects with the same values, these two objects do have equality and can therefore can be interchanged freely. When you can substitute one object for another, the object is a Value object (in other words, the value is in the object, rather than the identity of the object). You couldn’t interchange Entities because there would be unwanted side effects.

 

2. Overtime an Entity’s properties will change, but it will remain the same Entity. For example, if a user changes their email address. However when your application needs to change a Value Object property, the whole object needs to be destroyed and a new one should replace it. For example, when you make a payment, the money object isn’t given back to you as change, you are given a new money object of a lower value.

Domain Service , Application Service and Infrastructure Service

Domain Service :
Encapsulates business logic that doesn't naturally fit within a domain object, and are NOT typical CRUD operations - those would belong to a Repository.

* Domain Services along with your Domain Objects is sensible

Application Service :
Used by external consumers to talk to your system (think Web Services). If consumers need access to CRUD operations, they would be exposed here.

* Application Services will typically use both Domain Services and Repositories to deal with external requests.

Infrastructure Service:
Used to abstract technical concerns (e.g. MSMQ, email provider, etc)

3. Components of DDD.

Building Block of DDD

Add caption