Architecture of Enterprise Systems Domain Model and Database

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 1

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

Structure of layered systems: With 2 or more tiers: 1. Presentation layer: n 2. 3. Communication layer Service layer: n 4. Platform free object model Data source layer: n 6. Facade API, controllers, transactional actions Domain layer: n 5. Command line, GUI, Web, Phone 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 3

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 4

Domain model vs. DB layer • 2 tier: Presentations on top of DB. • • Data source layer: • • • Not appropriate for rich functionalities 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 5

Domain model vs. DB layer • Domain model: • rich with • • Implementation • • • Object aggregation Class hierarchy Interfaces Multiplicity constraints Association classes Complex values Inter-association constraints 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 6

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 7

Problems of Domain model – DB coexistence co-existence of storage and in-memory objects Mixture – ingoing and outgoing references: Ingoing: In-memory Persistent n Availability Outgoing: Persistent In-memory n Reference preservation Software Engineering, 2005 Design Patterns – Creational patterns 8 8

Problems of Domain model – DB coexistence Duplication handling: n Consistency– w Inter-layer – n Duplication of objects (Identity maps handling) n Duplicated references w Intra-layer – preventing duplication of objects Software Engineering, 2005 Design Patterns – Creational patterns 9 9

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

Current Technologies – e. g. , J 2 EE / Hibernate Necessary manual work: n Modification of persistent classes w Adhering to standards (e. g. Entity. Bean interface) n Mixture handling w Handle ingoing and outgoing references n e. g. serialization n Interlayer consistency w Object consistency n Manual invocation of, e. g. , session. save(obj), session. load(class, id), ejb. Load() / ejb. Store() / ejb. Create() / db. bind(…) / db. delete. Persistent(…) w Reference consistency n e. g. between two stored objects Workshop in SE project 11

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

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 13

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 14

Proxy Data Mapper Pattern Application precondition: message has a factory method Automatic application: n Extract subclass “Message. Imp” n Move implementation: Message. Imp n Add a Message. Data. Mapper n Add a Message. Proxy n Turn Message to be abstract n Redirect the factory method Software Engineering, 2005 Design Patterns – Creational patterns 15

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