Book contents
- Frontmatter
- Contents
- acknowledgements
- Introduction
- PART 1 ARCHITECTURE
- PART 2 DESIGN
- Chapter 3 Designing Application Servers
- Chapter 4 Service Interface Design
- Chapter 5 Designing Business Objects
- Chapter 6 Designing the Persistent Object Layer
- Chapter 7 Integrating Existing Systems and Legacy Software
- PART 3 PROGRAMMING
- Appendix: Setting up a Development Environment
- Index
Chapter 5 - Designing Business Objects
from PART 2 - DESIGN
Published online by Cambridge University Press: 06 July 2010
- Frontmatter
- Contents
- acknowledgements
- Introduction
- PART 1 ARCHITECTURE
- PART 2 DESIGN
- Chapter 3 Designing Application Servers
- Chapter 4 Service Interface Design
- Chapter 5 Designing Business Objects
- Chapter 6 Designing the Persistent Object Layer
- Chapter 7 Integrating Existing Systems and Legacy Software
- PART 3 PROGRAMMING
- Appendix: Setting up a Development Environment
- Index
Summary
The goal of business object design is to create a collection of reusable software objects that model your business. While interface design is a bottom-up approach, used to determine application requirements, business object design is a top-down analysis of the entire business, identifying roles and functions. Business objects are formed by specifying properties and services that reflect the real-world objects they model. As with real-world objects, software objects often combine and collaborate to perform tasks that they cannot perform individually.
Object design requires a global view of the organization, determining not only the needs of the current task, but the functions required for the entire business. Objects must be designed for reuse across both the current application and be ready for use in the next project, even if the project is for another department or a different line of business. Although not a simple task, it is not as difficult as it seems. Business objects mirror people, forms, and other objects that have already been integrated into the business. As such, when the objects simulate these functions, they also fit inside the same business context.
The object designer cannot possibly know all of the business requirements, so designing all functionality from the beginning is an impossible task. Business requirements are constantly changing and today's needs may not be relevant tomorrow. Business objects must be designed as open, dynamic components that can easily be changed without impact on other functions.
- Type
- Chapter
- Information
- Building Application Servers , pp. 91 - 128Publisher: Cambridge University PressPrint publication year: 2000