Downloaded 190 times
Uploaded byShweta Ghate
Domain logic patterns of Software Architecture
The document discusses different patterns for organizing domain logic, including transaction scripts, domain models, table modules, and service layers. It provides descriptions and examples of when each pattern is appropriate to use based on the complexity of the business logic and data model. Transaction scripts are simple and suitable for less complex logic, while domain models, table modules, and service layers are needed for more intricate business rules and relationships between objects, data tables, and application services.
In this document
Powered by AI
Introduction to Domain Logic Patterns presented by Shweta Ghate, guidance by Priya Deshpande.
Domain Logic describes algorithms for information exchange between databases and user interfaces, focusing on maintainability and scalability.
Key components: Transition Script, Domain Model, Table Modules, and Service Layer over Domain Model/Table Module.
Transaction Script organizes business logic using procedures for handling single requests.
Introduction to the Revenue Recognition Problem.
Transaction Script handles logic as a procedure with database calls, allowing for shared subtasks.
Business logic is organized by transactions such as hotel room bookings, involving various procedures.
Transaction Script benefits: independence of transactions, object manipulation at runtime, and simplicity for basic logic.
Domain Model combines behavior and data in an object model, suitable for complex business domains.
Highlighting the Revenue Recognition Problem again.
Domain Model supports complex business logic with structured options and behaviors, enhancing code readability.
Simple Domain Model mirrors database design; Rich Domain Model is more complex with patterns and requires Data Mapper.
Data Mapper separates Domain Model from databases, handling complex rules and requirements.
Domain Model issues with relational databases, leading to the use of Table Modules.
Table Module manages business logic for all rows in a database table or view.
Table Module organizes logic with one class per database table, packaging data and behavior.
Table Module facilitates business logic organization alongside tabular data results from SQL calls.
Grouping behavior with tables enhances encapsulation, enabling methods for data queries.
Table Module fits well with tabular data, maintaining organized application logic.
Service Layer defines application boundaries with a layer of services that manage operations effectively.
Service Layer components separate business logic into layers for reusability and structured applications.
Two main implementation styles: Domain Facade and Operation Script approaches.
Service Layer as thin facades over the Domain Model, with business logic contained within.
Thicker service classes implementing logic while delegating to domain object classes.
Service Layer classes facilitate remote invocations, enhancing domain object interactions.
Operation requirements determined by use case models and user interface designs.
Service Layer offers a common set of operations for diverse client needs, supporting complex transactions.
Service Layer enhances Domain Model APIs for clearer interactions.
Referencing 'Patterns of Enterprise Application Architecture' by Martin Fowler and related homework.
More Related Content
Similar to Domain logic patterns of Software Architecture
Domain logic patterns of Software Architecture
- 1. Domain Logic Patterns Guidedby :Priya Deshpande Presented By:Shweta Ghate
- 2. Domain Logicdescribe the functional algorithms or business logic that handle the information exchange between a database and a user interfaces. A well organized Domain Logic components are easy to maintain and scale.
- 3. Transition Script Domain Model Table Moduless A Service Layer is placed over an underlying Domain Model or Table Module
- 4. Transaction Scriptorganizes business logic by procedures where each procedure handles a single request from the presentation.
- 5.
- 6. A TransactionScript organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper Each transaction will have its own Transaction Script, although common subtasks can be broken into sub procedures.
- 7. With TransactionScript the domain logic is primarily organized by the transactions that you carry out with the system. For e.g.: If your need is to book a hotel room, the logic to check room availability, calculate rates, a the database is found inside the Book Hotel Room procedure
- 8. Advantages It is independentof other transaction. It allow you to manipulate instances of scripts as objects at runtime. When to use it…? Glory of Transaction Script is its simplicity . As the business logic gets more complicated ,we can move to the Domain Model.
- 9. Domain Modelis an object model of the domain that incorporates both behavior and data.
- 10.
- 11. More complexbusiness domains need to build in Domain Model. It will give you many more options in structuring the code, increasing readability and decreasing duplication. Domain Model mingles data and process, has multivalued attributes and a complex web of associations, and uses inheritance.
- 12. Simple DomainModel looks very much like the database design with mostly one domain object for each database table. use Active Record Rich Domain Model look different from the database design, with inheritance, strategies, and other patterns, and complex webs of small interconnected objects. requires Data Mapper
- 13. If youhave complicated and ever changing business rules involving validation, calculations, and derivations, chances are that you'll want an object model to handle them. Data Mapper which helps keep your Domain Model independent from the database and is the best approach to handle cases where the Domain Model and database schema diverge.
- 14. One ofthe problems with Domain Model is the interface with relational databases. If you have many orders, a Domain Mode will have one order object per order. To overcome such problems we move to Table Module.
- 15. Table Moduleis a single instance that handles the business logic for all rows in a database table or view.
- 16.
- 17. A TableModule organizes domain logic with one class per table in the database and a single instance of a class contains the various procedures that will act on the data. Table Module will have one object to handle all orders.
- 18. The strengthof the of Table Module is that it allows you to package the data and behavior together and at the same time play to the strengths of the relational database. We use Table Module with a backing data structure that's table oriented. The tabular data is normally the result of SQL call and is held in a Record Set that mimics a SQL table .
- 19. Grouping thebehavior with the table gives you many of the benefits of encapsulation. The Table Module may be an instance or it may be a collection of static methods. The Table Module may include queries as factory methods.
- 20. Table Moduleis very much based on table-oriented data ,so we can use it when we access tabular data using Record Set . Table Module allows you to fit business logic into the application in a well-organized manner, without losing the way the various elements work on the tabular data.
- 21. Service Layerdefines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations
- 23. Service Layeris a pattern for organizing business Service Layer factors each kind of business logic into a separate layer, yielding the usual benefits of layering and rendering the pure domain object classes more reusable from application to application.
- 24. 2 Basic implementationvariations are Domain facade approach Operation script approach
- 25. Service Layeris implemented as a set of thin facades over a Domain Model The classes implementing the facades don't implement any business logic but the Domain Model implements all the business logics The thin facades establish a boundary and set of operation through which client layers interact with the application, exhibiting the defining characteristics of Service Layer.
- 26. Service Layeris implemented as a set of thicker classes that directly implement application logic but delegate to encapsulated domain object classes for domain logic. A Service Layer is comprised of these application service classes, which should extend a Layer Supertype , abstracting their responsibilities and common behaviors.
- 27. Service Layerclasses are well remote invocation from an interface granularity perspective. Starting with a locally invocable Service Layer whose method signatures deal in domain object, we can add services remotability when we need it by putting Remote Facades on your Service Layer .
- 28. Identifying theoperations needed on a Service Layer boundary is pretty straightforward and they're determined by the needs of Service Layer clients. The starting point for identifying Service Layer operations is the use case model and the user interface design for the application.
- 29. The benefitof Service Layer is that it defines a common set of application operations available to many kinds of clients. An application with more than one kind of type of its business logic, and complex response in its use cases involving multiple transaction resources, it makes a lot of sense to include a Service Layer with container- managed, transactions, even in an undistributed architecture.
- 30. Domain Modelyou may want to consider Service Layer to give your Domain Model a more distinct API
- 31. Patterns ofEnterprise Application Architecture, Martin Fowler, Addison-Wesley Professional, 2003,ISBN-10: 0321127420 ISBN-13: 9780321127426 Paper :Homework 1 : Domain Logic , by Basanta Raj Onta (111701), Computer Science – August 2010.