What is "business rules"? Please explain with some example.
Businees logic is core logic to build
the application for the requirements.
But what is business rules?
BRMS = a set of tools to edit and execute business rules
JRules = a BRMS solution like JBoss rules, Blaze advizor, and much more
You want to use BRMS to externalize the business logic from the application.
It is the same as a database which is there to externalize data.
A business rule is atomic and represent a part of the business logic.
E.g:
"if the age of the applicant is less than 18 then reject the application"
BRMS is composed of:
- a rule repository (filesystem or DB)
- a developper (like Eclipse) and a business user (non technical) interface (web)
- an environment to execute the rules
You use BRMS in order to create a Decision Service.
It can be "callable" in J2SE, J2EE, EJB, Web Service, MDB, ...
Hence the businees rules which are part of a Decision Service (ruleapp/ruleset in JRules) can be called by various application.
The real advantage of a Decision Service.
Think of it like when a BPM needs to make a decision, rather than code the condition and actions in the application itself then make a call to a DS to have the answer, hence the decision.
It will takes you nothing more than 1 hour to create a dummy DS and call it from a BPM application such as Tibco Business Works.
Another definition of Business rules is that it is the result of a business policy implementation.
Business policy: "A good customer should be reward for the end of the year"
The Business Analyst job is to extract the rule from this statement and hence end up with rules like that:
"if the status of the customer is GOLD and the amount of the shopping cart of the customer is greater than £5,000 then set the status of the client to PLATINUM"
When you create the rule you have to ask yourself a lot of question like:
What about SILVER and BRONZE status? Are all the threshold covered by rules? and so on...
A Decision Service can potentially contain several thousands of business rules
For example: Some for validation, some for eligibility, some for quotation and so on...
Hope it helps
I don't understand your last sentence regarding TAG. But simply speaking, Business Rules are the rules which drive your business logic. For example in the banking domain - if the account balance is between this and this account status will be such and such, if the balance falls below such and such value, status will be something else and it will trigger some workflow like sending mail/email to the customer etc. This is just an example.
To isolate the business rules from the core application for reasons like better maintenance, separation of concern and allowing non-developers like subject matter experts to author and maintain the business rules the BRMS evolved. BRMS stands for Business Rule Management System. The piece of software which contains business rules. JRules is one such BRMS. Your application talk to BRMS to get the business rule information.
If you would like to see this in action with JBoss Business Rules Management System (BRMS) then you might like to try this repeatable demo:
http://www.schabell.org/2012/06/jboss-enterprise-brms-bpm-made-simple.html
It uses a simple walk through business process to visually demonstrate Rules integration (a Rules call is made from the process) to decide the path to take in the business process.
Hope you enjoy it. :)
Related
We have different client applications (each is built with a different UI and is targeted to a different sales channels) that are used to capture orders that ultimately need to be processed by our factory.
At first we decided to offer a single "order" microservice that would be used by all these client applications for business rules execution and data storage. This microservice will also trigger our backoffice processes such as client profile update, order analysis, documents storage to our electronic vault, invoicing, communications, etc.
The challenge we are facing is that these client applications are developed by teams that are external to ours (we are a backoffice team only). Each team responsible to develop a client application will be able to offer a different UX to their users (some will allow to save orders in an incomplete state, some wil allow to capture data using a specific worflow, some will use text fields instead of listboxes for some values, etc.).
This diversity of behaviors from client applications is an issue because our microservice logic will become very complex to be able to support all those UI requirements. Moreover, everytime a change will be made to one of the client applications, we will have to modify our microservice which is a case of strong coupling.
My questions are: What would be your best advice to manage this issue? Should we let each application capture the data the way it wants (and persist it if needed in its own database) and let them call our microservice only when an order is complete and compliant to our API contract?
Should we keep our idea of having a single "order" microservice for everyone and force each client application to capture the data the same way?
Any other option?
We want to reduce the duplication of data and business rules in our ecosystem but in the same time we don't want our 'order' microservice to become a mess.
Many thanks for your help.
Moreover, everytime a change will be made to one of the client applications, we will have to modify our microservice which is a case of strong coupling.
This rings alarm bells for me. A change to a UI shouldn't require a change to a backend service. (The exception would be if a new feature were being added to a system and the backend service needed to play a part in supporting that feature, but I wouldn't just call that a change to a client.) As you have said, it's strong coupling, and that's something to be avoided in a microservices environment.
Ideally, your service should provide a generic, programmatic API that is flexible enough to support multiple UIs (or other non-UI applications) without having any knowledge of how the UIs work.
It sounds like you have some decisions to make about what responsibilities your service will and won't take on:
Does it make more sense for your generic orders service to facilitate the storage/retrieval/completion of incomplete orders, or to force its clients to manage this somewhere else?
Does it make more sense for your generic service to provide facilities to assist in the tracking of workflows, or to force the UIs that need that functionality to find it elsewhere?
For clients that want to show list boxes, does it make sense for your generic orders service to provide APIs that aid in populating those boxes?
Should we let each application capture the data the way it wants (and persist it if needed in its own database) and let them call our microservice only when an order is complete and compliant to our API contract?
It really depends on whether you think that's the most sensible way for your service to behave. Something that will play into that will be how similar or dissimilar the needs of each UI is. If 4 out of 5 UIs have the same needs, it could well make sense to support that generically in your service. If every single UI behaves differently to the others, putting that functionality in your generic orders service would amount to storing frontend code somewhere that it doesn't belong.
It seems like there might also be some organisational considerations to these decisions. If the teams using your service are only frontend teams (i.e. without capacity/skills to build backend services), then someone will still have to build the backend functionality they require.
Should we keep our idea of having a single "order" microservice for everyone and force each client application to capture the data the same way?
Yes to the idea of having a single order service with a generic interface for everyone. With regards to forcing client applications to capture data a certain way, your API will only dictate what they need to do to create an order. You can't (and shouldn't) force anything on them about the way they capture the data before calling your service. They can do it however they like. The questions are really around whether your service supports various models of capture or pushes that responsibility back to the frontend.
What would be your best advice to manage this issue?
Collaborate with the teams that will use the service. Gather as much information as you can about the use cases in which they intend to use it. Discover what is common for the majority and choose what of that you will support. Create a semi-formal spec (e.g. well-documented Open API), share it with the client teams, ask for feedback, and iterate. For the parts of the UIs that aren't common across clients, strongly consider telling those teams they'll need to support those elements of their design themselves, especially if they represent significant work on your end.
I am writing a WS and I am building the architecture but I have some questions.
For example, my front application need to fetch a list of users. Each user have a list of accounts, authorizations, capabilities. I am displaying a this list of users and when I click on a specific user, I would like to display his details (list of accounts, authorizations, capabilities).
So what is the best way to architect my WS?
In my opinion, I will make first an endpoint to get a list of user (simple just with id and name).
When I click on detail, I call another endpoint to get user detail.
But should I have to separate list of accounts, list of authorizations, list of capabilities in 3 endpoints (one per functionality). Each one become reusable. Or should I call a single endpoint that return all informations?
What are the best practices in SOA?
So just using REST/SOAP services does not make your architecture SOA.SOA is an architectural style and set of disciplines and principles that can be implemented regardless of the underlying technology base.
How to design SOA services? Well the answer is really that this is decided in your SOA governance. WIthout governance SOA soon turns into a mess. So governance contrary to popular believe is not a set of restrictive rules on how to design your services, it defines a set of best practises and disciplines that you enforce to ensure maximum success of your solution.
SOA governance helps you make decisions during design and runtime. You mentioned you have SOA governance so what does your governance dictate.I would strongly suggest separate endpoint. Single responsibility principle is important.
A singular endpoint returning everything is going to be a pain to code, pain to maintain, pain to modify while being easy to call.
This is intended as a follow up question to RESTful API: Where should I code my workflow? A brief summary of the question (adapted to fit my question a bit better) would be something like this:
Each domain object contains business logic associated with the specific object in a certain bounded context (X). The REST API contains logic to transform the result of a query or command into data sent over the wire (JSON for example). When using HATEOAS and hypermedia we want to model relationships between resources using links. But in order to determine which links that should be returned by the REST API one often need to resort to business logic / rules. The question is, where do these "workflow rules" belong in a DDD application? Would they perhaps be in a different bounded context dealing only with the workflow rules (perhaps in a "partner"-like relationship with X) or would they belong in the X BC?
I'm not a DDD expert (only through 100 pages in Eric Evan's book) but I can tell you what happened in our case of a e-commerce catalog.
Initially we had such business flow in the same bounded context of the app based on data and the requesting user's roles/permissions we altered the state transitions (you said links, but this is really the heart of it, links are just one way to present state transitions) presented to the user. This worked ok, but it was a lot of repeated logic being executed. Then we added a search application that was a different bounded context as it presented the same data but in different collections/groupings and we didn't want to have them get out of sync.
We moved to a CQRS implementation, so a lot of our business logic is "pre-calculated" thus it's in something like a "partner context" as part of our projection from write model to read model. We don't store the links specifically, but instead flag allowed behaviours on the data. Both the catalog application and search application use this read model and it's behaviour flags to determine state transitions to present to the client.
Some stuff happens on the fly upon requesting of the resource, almost at the serialization step. We've targeted these to be moved to the pre-calculated as much as possible, but what we can't precalculate (only because of the scale) is stuff that is based specifically on the user. Like the recommended search which uses BI data within the search engine to return results. We could pre-calculate that for every single user, but the numbers are too huge for our systems right now. So we send the main apps calculated resource (from the main context) and pass it through yet another partner context to further refine things.
another use case is some links are only presented to authenticated user, and thus are hidden from anonymous users. We do this in the main apps context but it's starting to be a bit of a hindrance because their presence indicates what the user behind the request can do in other apps (like change password), and our context isn't really the authority of what the user can do in some other app. It would be nicer to hand the resource off to their context and have them process it before we return it to the user. One simple solution we used for this was instead of deep linking to functions within the external context, we link to a root resource of that context and allow it present state transitions. It means there's 2 requests, but it cleans up the locations/authorities of the logic.
The workflow is actually composed of domain knowledge and hateoas infrastructure.
If the application is not designed with hypermedia, you may not even need the hateoas part. But the domain knowledge still exists, they just live in the end users' minds. You need domain knowledge to validate the user's command just in case they forget it.
So for hateoas, I split workflow implementation into two parts: Domain models and hateoas infrastructure.
The domain models tell the domain knowledge.
The hateoas infrastructure, on the other side, is hateoas specific, put them out of the domain.
Here is a java example, using springframework-hateoas. I put the workflow in the procedure of mapping domain models to resources.
#Component
public class OrderResourceAssembler extends ResourceAssemblerSupport<Order, OrderResource> {
#Override
public OrderResource toResource(Order model) {
OrderResource resource = mapToResource(model);
resource.add(orderResourceHref(model).withSelfRel());//add self link
if (model.isAvailableToCancel()) { //let the model tell
//add cancel link
resource.add(orderResourceHref(model).withRel("cancel"));
}
if (model.isAvailableToPay()) { //let the model tell
//add payment link
resource.add(new Link("http://www.restfriedchicken.com/online-txn/" + model.getTrackingId(), "payment"));
}
//etc
return resource;
}
// omitted codes
}
If the model cannot tell on its own, you may introduce specification object to do the job.
Wherever the resource resides is the same place that needs to marshal the access to it.
Say you've got a larger system with three bounded contexts: employee management, customer intake, and service provisioning.
GET an employee's information from employee management? Deciding whether to show the link that can be used to POST or DELETE a role is for employee management to decide.
GET a freshly submitted service contract from customer intake? Deciding whether to show the link that can be used to PUT up a revision or POST follow up details is for customer intake to decide. Sure, employee management presides over the handing out of the roles necessary to work with new service contracts, but customer intake is responsible for knowing which claims and other conditions are required, and will ultimately ensure that everything checks out.
Likewise, GET a physical installation's software profile from service provisioning? Service provisioning is going to need to make sure that everything is in order with other services/contexts (customer's account paid up, current user in the network services role, device not locked out for maintenance) before it gives out the link where you can PUT the new quality of service specs.
These kind of 'workflow' decisions are integral to each context -- they should not be split out elsewhere.
I am, indeed, new to RESTful services and while I feel I understand the concepts I am resistant to some aspects of its use in my current project.
The project involves the provision of some form data from another system. Project members insist that the form data should be broken down into "resources" as there are customer and customer addresses etc on the form.
So its all about how granular the REST API is... the form data is not complete and actionable until we have all of the form data (and there's very little at that). And, in fact, I guess we will have to prepare some integrator on the service side to assemble all of these resource bits before we can use them because at present we have no persistence for them or, specifically, we have persistence for them but need to hide the data before it becomes actionable.
Again, at present this is point to point communications without any business case for sharing or service composition.
So, i'm of the idea that one service "form" using a POST is an acceptable optimization and do to the amount of work it cuts for us is a pragamatic approach.
What am I not getting about doing it the hard and expensive way?
If you don't need a high level definition in which you need to use a heavier structure with a well formed and heavy xml with its dtd, where you would be using a WSDL, etc. Then the best choice is REST, is lighter and use HTTP.
Here you can find a better explanation:
WSDL vs REST Pros and Cons
We are are going to be creating some RESTful services which are essentially going to be a passthrough to some ye-olde-fashioned SOAP-based webservices. The SOAP services are more generalized and will used across our entire organization (at least that's the plan). The RESTful services are tailored to specific clients. This decision was already made and is unfortunately out of my control to change...
We're struggling with how to structure our RESTful resources in a way that makes sense, follows REST best practices, and call these SOAP services without causing ourselves too much pain.
We have some freedom around the level of granularity for the back-end services, but the general consensus is: keep them coarse grained and don't tailor them to the specific client's needs.
This is leading to some interesting problems. For instance, how to deal with child resources of a parent. The typical example we've been working with is this: a customer with a child address.
We have a back-end SOAP service which updates a customer as a whole entity. However, the REST services client might need to update just the billing address. How do we best handle subsequent updates of the child resource?
Should we do the updates at the "parent" level (the customer), or expose a more fine-grained REST operation that treats the address as a resource and update it that way? The latter seems to be the correct, RESTful way. But, if we do that, we'll essentially be calling a coarse-grained backend service for just one piece of an update. Doesn't seem to make sense as it's a pretty heavyweight call.
We're also struggling a bit with how to correlate RESTful resources with our back-end domain model. We might care about the RESTful resource as a single entity but in our domain on the back-end, it might be many different entities. We've got a relatively simple DB table to handle this now, but I'm not convinced it will scale out as we map more and more resources to domain objects.
These are just a couple of examples of the things we're hitting... I'm wondering if anyone has run into similar issues and has any words of advice or might be able to point me to some articles that might have some best practices.
It seems like it this isn't an unusual problem and will become more relevant as more and more applications use RESTful architectures, but I can't seem to find any other info on it.
Thanks much!
I've found that most domains I model map very easily to REST. The most important thing to do is get into the right state of mind. REST models domains as a set of resources, where SOAP tends to emphasize a set of actions. Another way to look at this is that REST focuses on states and SOAP on state transitions. Even simpler you can think of REST as nouns versus SOAP as verbs. I know this isn't a perfect analogy but it's useful for me.
When you get into this state of mind the mapping should be almost automatic for you. Let's look at your Customer address interaction.
I don't think it's inappropriate to update the whole customer just to update the address, but not being familiar with your domain, maybe it is. If you want to specifically interact with the address just create a sub-resource (or nested resource). You end up with the following mapping of url's and verbs:
GET /customer/72/address # return the address of customer with id 72
PUT /customer/72/address # update the address of customer with id 72
In this particular case it probably doesn't make sense to map the delete, create or list actions.
If your customer has a collection of some entity, let's say widgets, you could map the interactions like this:
GET /customer/72/widgets # return the widgets of customer with id 72
POST /customer/72/widgets # create a new widget for customer with id 72
GET /customer/72/widgets/158 # return widget with id 158 of customer 72
PUT /customer/72/widgets/158 # update widget with id 158 of customer 72
DELETE /customer/72/widgets/158 # delete widget with id 158 of customer 72
Just have the right mindset and keep in mind the mapping won't be one-to-one and you'll be fine.
Don't try and model your domain entities as resources. Model your views/use cases as resources. There is absolutely nothing wrong with building resources for specific clients. REST encourages serendipitous re-use, i.e. unexpected re-use, it does not suggest you try and build resources that will work for every possible scenario.
RESTful frameworks should make resources really cheap and quick to create. If you need five different resources to model all the ways a customer is accessed, then that's fine.
In general I prefer to go with coarse grained resources, just because that is what HTTP is optimized for.