Upload
aubrey-wilson
View
216
Download
3
Tags:
Embed Size (px)
Citation preview
Architecture of Enterprise Systems: Domain Model and
Database layer
Worshop in Software Engineering ProjectDepartment of Computer Science
Ben-Gurion university
1Workshop in SE project
Structure of layered systems:
With 2 or more tiers:1.Presentation layer:
Command line, GUI, Web, Phone
2.Communication layer3.Service layer:
Facade API, controllers, transactional actions
4.Domain layer: Platform free object model
5.Data source layer: Data mappers, DB administration, transaction
managers, DB communication
6.Database
2Workshop in SE project
Structure of layered systems:
With 2 or more tiers:1.Presentation layer:
Command line, GUI, Web, Phone
2.Communication layer3.Service layer:
Facade API, controllers, transactional actions
4.Domain layer: Platform free object model
5.Data source layer: Data mappers, DB administration, transaction managers, DB communication
6.Database
Benefits of layered structure – for applications with• Changing requirements• Expectations for long life• Strong efficiency requirements on management
3Workshop in SE project
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!
4Workshop in SE project
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!
5Workshop in SE project
Domain model vs. DB layer
•Domain model: • 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
6Workshop in SE project
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
7Workshop in SE project
Software Engineering, 2005 Design Patterns – Creational patterns 88
Problems of Domain model – DB coexistence
co-existence of storage and in-memory objectsMixture – ingoing and outgoing references:Ingoing: In-memory PersistentAvailability
Outgoing: Persistent In-memoryReference preservation
Software Engineering, 2005 Design Patterns – Creational patterns 99
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
Current Technologies – e.g., J2EE / Hibernate
10Workshop in SE project
Support:Mapping: may be generated
automatically
Intra-layer ConsistencyAvailability – handled by the
environment EJB container
Current Technologies – e.g., J2EE / Hibernate
11Workshop in SE project
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
Fowler’s Active Record Pattern
13Workshop in SE project
Message'<<persistent>>
subjectbodyid
addSignature()addAttachment()insert()update()delete()
EditoSession'style
checkSpelling()alignLeft()alignRight()
editing
Problems:• Partial persistency
• Preserving references between objects
• Preservation of object availability• DB services imposed on the persistent
class
Fowler’s Data Mapper pattern
14Workshop in SE project
Problems:• Partial persistency
• Preserving references between objects• Preservation of object availability
• DB services imposed on the data mappers
Software Engineering, 2005 Design Patterns – Creational patterns 15
Proxy Data Mapper PatternApplication precondition: message has a factory methodAutomatic application: Extract subclass “MessageImp” Move implementation:
Message MessageImp Add a MessageDataMapper Add a MessageProxy
Turn Message to be abstract Redirect the factory method
Message
print() : String<<static>> create() : MessageProxy
<<persistent,abstract>>
MessageImpsubjectbody
print() : String
MessageProxyid
print()MessageProxy()~MessageProxy/Finalize()load()update()
MessageDataMapper
load(id) : MessageImpupdate(imp : MessageImp)store(imp : MessageImp)delete(id)
instantiates
11dataMapper
imp1