1. Architecture of Enterprise Systems: Domain Model and Database layer
Worshop in Software Engineering Project
Department of Computer Science
Ben-Gurion university
Workshop in SE project

2. Structure of layered systems:
With 2 or more tiers:
Presentation layer:
Command line, GUI, Web, Phone
Communication layer
Service layer:
Facade API, controllers, transactional actions
Domain layer:
Platform free object model
Data source layer:
Data mappers, DB administration, transaction managers, DB communication
Database
Workshop in SE project

3. Structure of layered systems:
With 2 or more tiers:
Presentation layer:
Command line, GUI, Web, Phone
Communication layer
Service layer:
Facade API, controllers, transactional actions
Domain layer:
Platform free object model
Data source layer:
Data mappers, DB administration, transaction managers, DB communication
Database
Benefits of layered structure – for applications with
Changing requirements
Expectations for long life
Strong efficiency requirements on management
Workshop in SE project

4. Structure of layered systems:
Imagine:
Millions of members in your Forums system, concurrently accessing the same forums;
Specifications change frequently:
New interactivity requirements;
Changing functionalities:
A group of members can post a message, owned by all;
Meta-search and message organization by message topic;
Member benefits: Club, points, social network;
Buy-sell forums; member bills;
Layer separation is essential for survival!
Workshop in SE project

5. Domain model vs. DB layer
2 tier: Presentations on top of DB.
Not appropriate for rich functionalities
Data source layer:
A must for handling Db access and actions.
Used for data mappers – that save explicit SQL management
Domain model:
Platform independent
Application independent
“Revealed” from tests about the domain, e.g.,
use cases
Requirements – constraints, non-functional specifications, descriptions
A stable reflection of the real domain!
Independent from the DB model!
Workshop in SE project

6. Domain model vs. DB layer
rich with
Object aggregation
Class hierarchy
Interfaces
Multiplicity constraints
Association classes
Complex values
Inter-association constraints
Implementation
Embeds object constraints in code
Adds design and implementation classes and interfaces
DB:
Tables of interconnected entities
Integrity constraints
Stored procedures
Workshop in SE project

7. Interaction between the Domain model and the DB
The Domain model cannot be a reflection of the DB  a poor domain model!
Assume that we design also the Data mode (DB). What are the timing relationships?
DB and then Domain Model, possibly by automatic translation?
Domain model and then data model using some standard data mapping techniques?
Independent design + mapping interaction
Data access mappers
Workshop in SE project

8. Problems of Domain model – DB coexistence
co-existence of storage and in-memory objects
Mixture – ingoing and outgoing references: Ingoing: In-memory  Persistent
Availability
Outgoing: Persistent  In-memory
Reference preservation
So let’s talk about the meaning of partial persistency…
Handling linkage of persistent to non-persistent objects
This mixture causes problems of ingoing/outgoing references.
Ingoing complication exposes the problem of availability: whenever an in-memory
Object is the client of an in-memory one, we want to make sure that the persistent
Object is available whenever it is required by the in-memory one.
Outgoing complication exposes the problem of reference preservation: whenever a persistent
Object is store, how to make sure it is reconnected to an assosiated in-memory object
When it is reloaded. Not loosing in-memory objects.
For example: In the picture: Element1 & Elements3 are stored objects.

9. Problems of Domain model – DB coexistence
Duplication handling:
Consistency–
Inter-layer –
Duplication of objects (Identity maps handling)
Duplicated references
Intra-layer – preventing duplication of objects
So let’s talk about the meaning of partial persistency…
Handling linkage of persistent to non-persistent objects
This mixture causes problems of ingoing/outgoing references.
Ingoing complication exposes the problem of availability: whenever an in-memory
Object is the client of an in-memory one, we want to make sure that the persistent
Object is available whenever it is required by the in-memory one.
Outgoing complication exposes the problem of reference preservation: whenever a persistent
Object is store, how to make sure it is reconnected to an assosiated in-memory object
When it is reloaded. Not loosing in-memory objects.
For example: In the picture: Element1 & Elements3 are stored objects.

10. Current Technologies – e.g., J2EE / Hibernate
Support:
Mapping: may be generated automatically
Intra-layer Consistency
Availability – handled by the environment
EJB container
Workshop in SE project

11. Current Technologies – e.g., J2EE / Hibernate
Necessary manual work:
Modification of persistent classes
Adhering to standards (e.g. EntityBean interface)
Mixture handling
Handle ingoing and outgoing references
e.g. serialization
Interlayer consistency
Object consistency
Manual invocation of, e.g., session.save(obj), session.load(class,id), ejbLoad() / ejbStore() / ejbCreate() /
db.bind(…) / db.deletePersistent(…)
Reference consistency
e.g. between two stored objects
Workshop in SE project

12. Example: Application Development Process
Example: an client system
Workshop in SE project

13. Fowler’s Active Record Pattern
Problems:
Partial persistency
Preserving references between objects
Preservation of object availability
DB services imposed on the persistent class
Workshop in SE project

14. Fowler’s Data Mapper pattern
Problems:
Partial persistency
Preserving references between objects
Preservation of object availability
DB services imposed on the data mappers
Workshop in SE project

15. Proxy Data Mapper Pattern
Application precondition: message has a factory method
Automatic application:
Extract subclass “MessageImp”
Move implementation: Message  MessageImp
Add a MessageDataMapper
Add a MessageProxy
Turn Message to be abstract
Redirect the factory method

16. Transactional activities
Can be in-memory
No explicit handling of transactions
Can be in the service layer
Brings to memory all necessary stored objects
Stores at the end
Persistence is transparent to domain layer
Risk: Messy service layer, thin domain model
Workshop in SE project