Note: This article primarily deals with constructing fairly large Line of Business applications. If you are building control systems or software that is more oriented to be used within other applications (Graphics Libraries, ORM’s, etc…), this article may not apply to your type of development. But who knows, we are breaking new ground here.
If you read my last post, I’ve asserted that when constructing a typical LOB type application, you should focus on your data model and work up from there. The thought being that the most static part of your system will be the data and it’s relationships.
I’m not going to dwell on it here, but I think some sort of ORM should be placed on top of that data model. ORM’s are really a commodity. They all have their strengths and weaknesses. If you’re not using some sort of ORM you should at least see what they have to offer. My ORM Smackdown project is a good place to check out different ORMs. Although your technology for implementing a data model and an ORM might change, I will submit in one-way-or-another, these two components are fairly “settled law”.
As we start moving up the stack, the next layer is business logic. The business logic layer is where most of the code for your application should live and is going to be somewhat dynamic with respect to time and changes in the business. Yes, there is the potential for changes to happen to your data model, but if you have enough systems under your belt you know most of these changes are additions, not changes to the structure. At a very high level there are two components of a the business logic layer, Business Rules and Functional Requirements.
According to Wikipedia a Business Rule is defined as:
A statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business
And a Functional Requirement is defined as:
A functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs
Oslo has the potential to change change the way we enforce the Business Rules and satisfy the Functional Requirements in our business logic layer.
Before I go too much further, I’m going to make a claim that I’ll need you to think about before we go too much further.
There are two primary activities that a user or other system does when they interact with a system. 1) Annotate “something” with some additional data via user entry, calculation or call to a service. 2) Interact with “something” to enable a future state of that “something” based upon constraints.
This might not be obvious when you are building your software, but at a certain level of abstraction if you think about out it, these are probably valid statements.
Let’s bring this back to Oslo
As I stated before Oslo provides us mere mortals a mechanism of quickly and easily constructing a grammar or Domain Specific Language (DSL). So the idea is that we build up small highly configurable “chunks” of functionality that could very easily be unit tested. Then we use a DSL to glue these together to satisfy the functional requirements of the systems we are constructing.
Let’s take the example of submitting an invoice. We are going to model our invoice as a finite state machine. This sample is a greatly simplified business flow but let’s assume our invoice as three states, “New”, “Submitted” and “Paid”. Our first syntax will be used used to define our states. It might be something like:
The states of our invoice are New, Submitted and Paid.
This defines a new entity or object in our system called Invoice. It also defines that state our invoice can be in, which are New, Submitted and Paid.
Next we need to define some business rules, these could be defined as something like:
The invoice can transition between New to Submitted and from Submitted to Paid.
This maps the business flow that the invoice must follow. It is possible for an invoice to go from New to Submitted but it is not possible for it to go from New to Paid. This is obviously a simple process flow but for a more sophisticated process flow, I’m sure you could see how this might be useful.
Now if we want to add some additional states to our system we can use the following grammar.
The states of our invoice are New, Cancelled, Submitted, Overdue and Paid.
To make things a little more interesting, our transitions will then be updated to:
The invoice can transition between New to Submitted, New to Cancelled, Submitted to Cancelled, Submitted to Overdue, and from Submitted to Paid.
Defining the states and transitions is the foundation and first step as well as something that can easily be managed by a DSL.
This is the first layer we will be using to define business rules and functional requirements, there is much more to come, but this seems like a good place to end this post. In our next post we show how we can use “M” to take the syntax and turn it into something that is useful for a computer. As we progress through these posts, I will probably do one post like this that introduce the concept and a follow up on how that concept would be implemented in Oslo.
Until next time…
-ec
No comments:
Post a Comment