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

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

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

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

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

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

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

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.

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.

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

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

Example: Application Development Process Example: an e-Mail client system Workshop in SE project

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

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

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

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