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

Example: Application Development Process

12Workshop in SE project

Example: an e-Mail client system

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

Transactional activities

16Workshop in SE project

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