DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Don't Model Business Behavior in Objects!

Don't Model Business Behavior in Objects!

Modeling a business requirement is more efficient with an object model. Workflow engines and BPMN 2.0 are powerful extensions to object-oriented business apps.

Ralph Soika user avatar by
Ralph Soika
·
Mar. 15, 17 · Opinion
Like (2)
Save
Tweet
Share
3.47K Views

Join the DZone community and get the full member experience.

Join For Free

during the past few years, i've seen many projects where nearly any kind of business requirement was modeled into the technical object model, independent of the reason for the requirement. in many cases, modeling business requirements into a technical object model is quite ok, and i agree with it in general. however, modeling business requirements into the affected business objects can also lead to an ugly and complicated data structure. let's look into a short example to illustrate my thoughts.

let's assume that we have an imaginary software project. the goal is to build an online sales system for a small car manufacturer who is selling sports cars. (maybe i've seen such a similar problem at a large car manufacturer in the past.)

our system deals with cars and orders, so we can design a typical technical object for the order process into a data table like this:

table-1

table 1.

the order table has a unique id, a model type, a price, and a color. this is enough data to manage an order in our case. however, in an agile software project, the business requirements typically change and evolve during the development cycle very quickly. so, one day, the marketing team tells us that the color of a car can only be changed by the customer until the car was ordered. we believe that this new requirement is essential and we begin extending our existing technical object model by adding new attributes:

table-2

table 2.

our web developers can easily check the new flag isordered to decide whether the color selector is still available in the gui.

modeling business behavior

what we have done so far is add a new business behavior into our technical object model by changing the database schema. is that a wise strategy?

the alternative that i want to propose here is the design of a business process model instead of an object model. if we have a workflow engine, we could model the given requirement like this:

image title

now we have modeled the different business states into a new business process model called car order . the information about whether the car has been ordered has moved into a bpmn 2.0 business process model. a workflow engine can read such a model and synchronize a new process instance with this model. so, when we now link our technical object model with the business process, we can still go on with our initial first object model version table 1 . our web developers can simply ask the process state against the workflow engine to decide whether the color selector should be available.

....
// load a process instance by id...
workitem=workflowservice.getworkitem(id);
if ("ordered".equals(workitem.getitemvaluestring("$workflowstatus"))) {
   ....
}

a workflow engine manages not only the process flow but also all information about the process, such as the creation and order date and all the actors involved in the process.

one object model, many business models

let's go further increasing the complexity. one day, our marketing team brings up another new idea: vip customers!

vip customers should be allowed to change the color of a car — even 30 days after ordering. back to the concept of modeling such requirements into the technical object model, this can lead to a more and more ugly data design like this:

table-3

table 3.

we have added a new flag indicating vip customers and also additional data about the possibility to change the color.

(don't argue about the data modeling here; this is only for demonstration purposes, and we all know that data models can grow very quickly and can be designed in different ways. but this shouldn't be the point here.)

our car_order table now looks not very trustable, even if we split it up into different tables. we can't that this was the last idea of our marketing team. but what would be the solution in case we use a workflow engine? the strategy looks very different.

the new requirement of vip customers is indeed simply another business case. so, we can create a different process model reflecting the requirements to those kinds of new customers. our new process model for vip customers can look like this:

image title

this alternative process model defines now a new state pre-ordered . this task contains a timer event which monitors the order date and automatically updates the state of the order based on time period defined by the model. again, we do not need to change the technical object model here! we simply assign new orders for vip customers with a different process model. also, our web development team has no need to change anything. still, the color selection is hidden if the status ordered is reached. this all is defined by our new process model and can be controlled by the workflow engine.

one process, many views

i want to extend the requirements once more to dive deeper into the idea of business process management. our marketing team brings up a new family car series. this is, of course, a fancy, great new idea! the requirement is that families will be allowed to change the color of the car even after they have ordered the car — but this change must be agreed with the production team. i'll spare you the draft design of an even crazier data model here. let's look like a new business process model will reflect this requirement:

image title

what we have done here is simply move the task ordered into a separate lane. a lane in a bpmn 2.0 model defines a specific actor in a business process. by moving a task into a lane, the task is assigned with a different actor — in our case, the production team.

human-centric workflow engines like imixs-workflow are specialized in modeling such user-centric behavior. each task can be assigned to different persons, groups, or roles. the access level can be modeled in a fine-grained way by assigning the read and write access to different actors.

image title

so, what we do here is simply change the write access of the ordered task to our production team. this means that only the production team is allowed to modify the process instance during the task ordered '.

for our web developers, this means that they can ask the workflow engine if the current user is still allowed to change the process data:

....
// load a process instance by id...
workitem=workflowservice.getworkitem(id);
if (("ordered".equals(workitem.getitemvaluestring("$workflowstatus")))
    &&
    (workitem.getitemvalueboolean("isauthor"))) {
   ....
}

with this new process model, members of the production team will see the color selector and will be allowed to change the data even if the car is already ordered — but the family members may only see a message to ask the sales agent if a further change of color is possible.

note that we still did not make any change to our original data model, but through the use of a workflow engine, we solved three very different requirements with three separate process models!

conclusion

what i wanted to show you here is that modeling a business requirement in a business process can be much more efficient as in the object model. with the help of a workflow engine, you can change the behavior of an application without changing your technical data model. at the present time, where agile projects have become self-evident, a software system should provide the ability to implement changing requirements independent of the technical object model. workflow engines and bpmn 2.0 are a powerful extension to object-oriented business applications.

Object (computer science) Database Workflow engine Requirement Business process Object model agile Data (computing) Business requirements Software system

Published at DZone with permission of Ralph Soika. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • The Future of Cloud Engineering Evolves
  • Unleashing the Power of JavaScript Modules: A Beginner’s Guide
  • Top Five Tools for AI-based Test Automation
  • Exploring the Benefits of Cloud Computing: From IaaS, PaaS, SaaS to Google Cloud, AWS, and Microsoft

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: