1 / 27

Architecture

Architecture Natty Gur Introductions Enterprise architecture Actually 5 different but tightly couple architectures Business. Application (our main focus) . Software. framework Technological Analyze against several view points (matrix) : Enterprise Information. Componential.

libitha
Download Presentation

Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecture Natty Gur

  2. Introductions • Enterprise architecture • Actually 5 different but tightly couple architectures • Business. • Application (our main focus). • Software. • framework • Technological • Analyze against several view points (matrix) : • Enterprise • Information. • Componential. • Engineering • Technical.

  3. Introductions • Enterprise architecture framework • Set of methodologies, frameworks in frameworks and practical guide to create architecture. • Frameworks: • TOGAF • URL : http://www.opengroup.org/architecture/togaf/. • RM-ODP • URL : http://www.enterprise-architecture.info/EA_Standards.htm & Books • Zachman • URL : http://www.zifa.com/

  4. Introductions • Software/Application Architecture are: • Set of rules to define software/s building blocks, relations between those blocks, there position over the enterprise and which kind of blocks to use: • Of the shelf. • Reusing. • Developing. • Architecture main guiding points are: • Coherent with enterprise goals (driven and NOT leading). • Abstraction. • Loosely coupled.

  5. Enterprise continuum • Database of available architectures and patterns whether used or unused in your enterprise. • Add metadata such as : • Add by (who can I ask questions). • Implement by systems. • Link to any sources. • Add draw (one picture worth …) • Should be use when creating Architecture to reuse existing resources. • I’ll open wiki/site for that purpose, details - blog.

  6. Enterprise continuum – partly list • System structure • Layers. • Hexagonal. • Naked objects. • Entity oriented. • Pluggable. • SOA. • Domain Logic • Transaction script. • Table module. • Domain model. • Service layer. • DB mapping • Row gateway. • Table gateway. • Active Record. • Mapping. • Lazy load. • Presentation • MVC – MVC II. • Front controller. • Page controller. • Application controller. • State management • Server. • Client. • Database. • Hosted network node. • Business transactions • Optimistic. • Pessimistic. • Crouse-grained. • Implicit. • Storing objects in DB • Single table. • Concrete • Table. • Double.

  7. Glorious days of layers • Concept – Systems building from components. • Motivation – separation of components by functionality for maintains and reuse. • Description – • Ordering components in layer. • Each inner layer should be called by outer layer. • No direct call to inner layer. • (Layer vis Tier). • Advantage – • easy to follow. • Split system into well define behavioral components. • Problems – • how to access inner layer (for debugging purpose). • How to enable unknown consumers to call system (System of systems).

  8. Hexagon Architecture • Concept – UI/DAL aren’t always the “external” layers. • Motivation – No more layers. Every system “service” might use or call domain logic • Description – domain exist in the center and can be access by or access any “external services” via transformers. • Advantage – • More flexible. • Suite system of systems. • Problems – • not imposing strict system flow. • Takes time to get.

  9. Entity oriented Architecture • Concept – Enterprise domain build from Information entity. • Motivation – Enable SOS that integrate UI,BL and DA. • Description – Entity expose services. Once certain services call the flow is strict as in layers. • Advantage – • Combination of Layers and Hexagonal advantage. • Helps system 80% maintains. • Problems – Hard to implement. gateway UI BL X DA

  10. Naked objects • Concept – Defining system flow and logic in advance is wrong! • Motivation – enable sequence less systems for maximum user flexibility. • Description – creating just classes. Framework enable the user to create objects from classes and act upon them. • Advantage – Flexible!!! • Problems – demand Infrastructure.

  11. Naked objects - Demo

  12. Pluggable architecture • Concept – systems create from components therefore can be assemble dynamically. • Motivation – Creating easy to change and maintain systems. • Description – Every connection between components depend on Interface. Component call others by global name. External definitions (XML) set which actual class will be call for given global name. Or external file set which components will be load at system load. • Advantage – • enable easily component replacing. • Enable assembling dynamic systems (versions). • Problems – demand work.

  13. Pluggable architecture - Demo

  14. Domain Logic • Transaction script. • Every transaction with all of activities in one function. • Advantage : Easy to create. • Disadvantage : duplicate code, problematic with complex logic.

  15. Domain Logic • Domain model.. • OO reflection of logic and data. • Advantage : most flexible and feet complex logic. • Disadvantage : Lots of work (design and mapping) • Simple & complex • Store in OODB or session.

  16. Domain Logic • Table module. • Reflection of DB. Every table has class that handle table activities. • Advantage : well adopted in .NET. • Disadvantage : Can’t deal properly with complex logic. Less easy to maintain code (Flexible).

  17. Domain Logic • Service layer. • Handle application flow. • Exposing one interface of services to the outside world. • Advantage : callers not need to know inner system implementation. Easier to control outer request that required several actions in domain logic

  18. Mapping to DB • Table gateway. • Mapping DB table to domain logic class. • Hides SQL in one place. • Stateless, just push data back and forth. • Returning map, value object, record set (.Net).

  19. Mapping to DB • Row gateway. • Mapping each table row to dedicate object. • Row gateway class handle just DB actions. • Mixing DB access with logic more complex to test and maintain. • Usually finder class added. • Convert data source types to in memory types.

  20. Mapping to DB • Active record. • Record mapping and logic exist in one class. • Fit for simple domain model.

  21. Mapping to DB • Mapping. • Special class to translate DB data to domain logic OO structure. • Collection and inheritance for example. • Data classes are ignorance of data source, complete de-coupling. • COMPLICATED! Use ORM tools.

  22. Domain Logic & DB mapping sample • word processors, databases, and spreadsheets revenue calculation.

  23. OO structure to DB • Single table inheritance. • Concrete table inheritance. • Class table inheritance. • Double mapping.

  24. Presentation • Page controller • Front controller • Application controller • MVC

  25. Object-Relational Behavioural Patterns • Unit of work: keep track of changes. • caller registration. • object registration. • unit of work controller. • Lazy load. • Initialization. • virtual proxy. • value holder. • ghost. • Identity map.

  26. Offline concurrency • Optimistic lock. • Pessimistic lock. • Coarse-Grained Lock. • implicit

  27. Books • Pattern Oriented Software Architects POSA I – II (ISBN 0471958697 ,ISBN: 0471606952). • Patterns of Enterprise Application Architecture (ISBN-0-321-12742-0).

More Related