Architecture of Enterprise Systems: Domain Model and Database layer

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 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 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

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

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: • Modificationof persistent classes • Adhering to standards (e.g. EntityBean interface) • Mixturehandling • 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: an e-Mail client system Example: Application Development Process 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. 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 Transactional activities Workshop in SE project