This page is an audio transcript of the video at right, which summarizes the key elements of building Enterprise-class database web applications using Domain Driven Automation.
Introduction: agility / complexity are business / technology challenges
Scaffolding for database web apps is a big step over starting from scratch. But it still requires far too much slow and complex coding to deliver deployable apps, with polished User Interfaces and complex, multi-table business logic.
The impact is significant. At the business level, IT is failing to deliver the agility required support the business. And Business Users are frustrated - they often envision such apps as scarcely more complicated than a spreadsheet. At the technology level, the complexity is diminishing the value of the Java ecosystem, as teams are forced to other faster/simpler technologies.
Solution requires full-scale automation
Turning to new languages is undesirable, since it does not preserve the valuable Java ecosystem. And it does not solve the problem - code is still code.
A solution requires we move beyond the presumption of code, raising the level of abstraction from the technology to the business, so that building a system is as easy as imagining it.
We can do this by extending Convention Over Configuration to Model Driven Automation, where JPA Model Annotations automate polished User Interfaces and complex multi-table business logic in all but the exception cases.
We characterize this as Domain Driven Automation. Let's see how it works.
Let's have a quick look at our target - a representative database web app, starting with Part I, the User Interface:
- Browsing: filtering, multi-column paginated lists, and detail drill down to view related data
- Rich interface: including groups, tab sheets, ajax interactivity, and advanced controls such as calendars, rich text and images.
- Multi-table: Master/Detail (Purchase Order with a set of LineItems, with joined Product data), with services to Choose referenced data (e.g, the flashlight provides filterable lists to choose a Customer for a Purchase Order).
Which brings us to Part II - the business logic - often half the effort in a database oriented application. Summarized by the familiar cocktail napkin, it governs a set
of Use Cases. So beyond the obvious Use Case like Place Order, logic must address:
- paying an order
- deleting an order
- reassigning a Purchase Order to a new Customer
- adding a Line Item
- deleting a Line Item
- changing a Line Item Quantity
- re-assigning a Product
- And all of our multi-table derivations are governed by constraints, so for example the balance cannot exceed the credit limit.
Moreover, these of Use Cases goes well beyond JSR-303 single-attribute validations. Each of these are complex multi-table transactions, involving multi-table derivations that must be sequenced and optimized. Such multi-table requirements often lead to a complex service layer. For example, re-assigning a Line Item's product requires we recompute the partPrice, the amount, the amountTotal, and the balance - and ensure this is within the credit limit.
Domain Driven Automation
So, how does Domain Driven Automation enable us to build such an application?
Automation starts with a Domain Driven Design
. To leverage Java, we express this as a standard JPA Model - a set of annotated Domain Objects (POJOs), such as Customer, Purchase Order and so forth. We have used Groovy since it eliminates the accessors and makes the model quite apparent. You can also use Java.
Click the thumbnail at right to see the detail.
Convention over Configuration
From just this model, OpenXava employs Convention over Configuration to build a complete web application. This requires no code, no code generation, not even html/jsp files. The entire app is derived from the model.
This application compares quite favorably to familiar scaffolding products. It provides all of our browsing / filtering, screen transitions, master/detail, etc.
But, it is not a polished application. Users would expect to see groups and tabs, rich text, images, and better presentation / choosing of related data.
Automate Presentation from Annotations
So OpenXava extends the state of the art by introducing annotations, used to automate the entire application we saw above. For example, this Pruchaseorder
@View annotation defines the groups and tab sheets presented on the Purchaseorder form. The
@ListProperties annotation defines the content of the
lineitems list, and
@DescriptionsList specifies the use of a combo box to choose the Product.
Automate Complex Business Logic From Annotations
Which brings us to the Business Logic. ABL uses the exact same annotation-based approach to automate complex multi-table business logic. In fact, the annotations correspond exactly to the cocktail napkin we saw above.
We declare a Logic class for each Domain Object. The Logic classes are shown - in their entirety - below. Let’s look a bit closer.
Here we see the Customer Constraint that the balance cannot exceed the credit limit. The balance is derived as a sum of the related Purchase Order’s amountTotal for unpaid / ready orders. The amountTotal is itself derived as the sum of the Line Item amounts, which is the quantity times the Products’ price. Complex Business Logic - chained, multi-table derivations.
And that’s it - our annotations correspond exactly to our cocktail napkin - executable requirements. No code, in fact, more like the spreadsheet our Business User had in mind.
The basic architecture is shown here. You simply supply your annotations for presentation and business logic. OpenXava uses these to automate the complete User Interface, using the JPA Model for both meta data (including the annotation extensions) and data access.
JPA updates publish events that are handled by the ABL runtime, which locates your logic, analyzes its multi-table dependencies, and executes it in a correct and efficient order. Event-driven logic enforcement applies to al updates, whether from OpenXava, or from a Services layer.
While remarkably simple, automation is extremely powerful:
- Reuse is automatic. So, as we saw in the demo, logic imagined for place order is automatically re-used for choose Product, delete Line Item, pay order and so forth. Integrity is automated, since it does not depend on manual programming calls.
- Optimizations are also automatic. For example, the customer balance is computed by 1 row adjustment updates, avoiding the geometric reads of all the orders and the related line items. And logic is pruned to eliminate database overhead - changing the order Notes does not activate adjustment logic.
- Finally, ordering is automated, based on automatic dependency analysis. So, for maintenance, you simply change the logic - no more archaeology to decipher the ordering of a previous implementation.
Logic is extensible
using conventional Java/Groovy approaches. It does not interfere with decisions regarding a Service Layer
- in fact, it can make your service layer thin by factoring out complex multi-table logic.
The higher level of abstraction (business / declarative vs. technology / procedural) enables the same app to be rendered on a mobile platform, without changes:
What about Real World complexity?
The example above is designed to communicate the point as simply as possible. But of course, your application will likely contain more complicated requirements, so it's important to understand whether these are addressed.
- A Bill of Materials Price Rollup with 4 rules (a bolt is used in a Wing, Engine, etc - how does a price change affect the cost of a plane?)
- A Bill of Materials Part Explosion with 3 rules (how many bolts remain in stock after building n planes?)
- An Allocation of a Payment to a Customer with 4 rules (which Purchase Orders are paid off, and what is the resulting balance?)
- Copy examples, such as auditing or cloning a Purchase Order and its Line Items
ABL logic can be expressed not only in annotation, but also in Java/Groovy methods. There are thus no restrictions on the scope of your logic, enabling you to address enterprise concerns such as application integration.
Model Driven Automation is best suited to "in-house" applications where the User Interface must be polished and easy to learn, but need not be "gold plated" for a customer-facing application. For such in-house applications, there is well over an order of magnitude reduction in the scope of the development effort:
| Application Element
|| Domain Driven Automation
| JPA Data Model
| Screen code/html
|| Significant expertise difference
| Business Logic
|| 500 - shown here
|| Significant expertise difference
Note these raw code counts do not take into account expertise difference, or implications for maintenance effort.
So, OpenXava and ABL can make your organization much more agile
in responding to business change. As shown above, this entire app took 15 annotations. By contrast, the business logic alone required 500 lines
of code using a traditional approach for dependency management over multiple User Cases. With Domain Driven Automation, in 20 minutes you can rebuild
this entire application (starting with the data model).
It’s very easy to adopt – automation eliminates the complexity of the Java stack while preserving its value, so you are productive immediately, with a very small learning curve to master the declarative approach. Both products are Open Source. Importantly, the declarative services can be extended using standard Java.
And automation results in Enterprise-class applications, with the expected levels of polished User Interface, adherence to standards, automatic integrity, and scalable performance.
Finally, annotations are simple enough to be transparent to Business Users, enabling a new era of partnership between IT and the business.
We encourage you to download the product, and review the Tutorial.