Hot answers tagged business-rules
17
I have seen it. Didn't end up well.
I think that cucumber is cumbersome (<--lol :D) abstraction for this exact reason. Too hard for non-technical people to write by themselves; too verbose for technical people.
Non technical people just haven't learned to think like programmers. It is our privilege to understand abstract knowledge, break it down, ...
11
Exceptions to business rules are generally not exceptions -- they are almost always simply more rules. So, the first thing I'd do in this case is ask WHY this particular record is an A but gets treated as a B. Where and how is that decision recorded?
If the answer is that it's recorded outside of the data that your process has access to, then the ...
11
If you mean representing individual business rule checks with exceptions, then I don't think it's a very good idea. Many times you have to report more than one failed condition, and not stop on the first one.
On the other hand, I do believe that checking for all rules and then throwing an exception with the summary is a good practice.
11
Business logic doesn't go into the database
If we're talking about multi-tier applications, it seems pretty clear that business logic, the kind of intelligence that runs a particular enterprise, belongs in the Business Logic Layer, not in the Data Access Layer.
Databases do a few things really well:
They store and retrieve data
They establish and enforce ...
8
In the example you've given us I think that raising an exception is a bad idea. If you know that the user is not authorized before they start working and you still allow them to do some function and then smack them with an message AFTER they've already completed the task, that's just a bad design.
Using exceptions to enforce business rules is not a good ...
7
This is one of the use cases for BDD frameworks, like Cucumber, that allow you to capture the business requirements in code and test against those requirements frequently. Other approaches I've seen used include long and complicated specification documents, large sheets of paper tacked to the wall, slide decks, and Joe, the guy at the end of the table who ...
7
Part of the difficulty in terms of the customer writing a specifications document is that the customer often doesn't know how to translate the things the customer wants into a language which actually describes what the customer needs. While the customer may say that they want a certain behaviour to exist in a system, they are generally not so concerned with ...
6
We've had basically the same experience where I work and we've addressed it by having a OrderBusinessLogic class. For the most part the layout you've described works for the majority of our business. It's nice and clean and simple. But on those occaisions where you have buy any 2 from this category, we treat that as an "business execption" and have the ...
6
I would use WF or Drools if you're trying to create an abstraction that non-programmers could work with to develop business rules. However, if you're dealing with programmers than the abstraction of WF isn't worth the time it takes to develop a solution, I fail to see the added value for your investment.
A database is a good way to maintain rules that ...
5
I would focus on use-cases and user-stories. I could document them, perhaps in a wiki, and give each one an ID (like UC00001). Then when I wrote unit tests and/or integration tests, I'd label them with the use case they inform.
Then when I get to two unit tests that can't both pass because they're mutually exclusive, I'd throw those two use cases back at ...
5
If you consider that a Customer is a part of the domain model, then it makes sense (especially within the context of DDD but not limited to it) to have have both properties and operations for that object.
With that said, however, I think that the example you've used is a poor one, and is a cause of the argument. If you're talking about persistence, then ...
4
I don't see what value throwing an Exception has in creating good business logic. There are dozens of approaches to handling business logic that do not involve using a system that is meant for addressing unexpected conditions in the operation of a system.
It is expected that in business logic, conditions will not be met; that's the reason for having it in ...
4
The decision as to whether to expose an interface for non-technical personnel to modify business rules largely depends on several factors, including the goals of the project, cost of the project, lifetime of the project, and the ratio of knowns to unknowns in the project.
For instance, if I believed that no one would use the rules interface, then I would ...
4
If you are guaranteed that there will be exactly one of of the "special" records and that it can be identified easily (i.e., by its id in your example), option 1 is just fine. Don't hard-code the record ID into the program; accept an optional value from the command line or whatever way your environment lets you specify these things:
% process-records ...
4
What you’re asking for is essentially a domain-specific language—a small programming language for a narrow purpose, in this case defining P&P RPG rules. Designing a language is in principle not difficult, but there is a considerable amount of up-front knowledge that you must gain in order to be at all productive. Unfortunately, there is no central ...
3
The fields are part of the conversation that should be had. They may be written down if that is useful but that is a judgment call. Keeping the documentation up to date may be challenging whereas the working software could be seen as documentation to some extent.
User Story - A Promise to have a conversation would be a blog entry about this.
Your trivial ...
3
My experience working with extremely complex business logic and a domain expert is that the time of the domain expert tends to be extremely valuable, even more so in a small sized company.
He is of course rattling off endless details and nuances to you because it comes naturally to him for one, and secondly because he is likely an extremely busy person. ...
3
Probably the most common form is Use Cases. You can supplement them with screen mock-ups and descriptions.
A book I'd recommend is "Writing Effective Use Cases" by Alistair Cockburn. It describes how you can write use cases at various levels of detail, how to avoid falling for the 'template' driven approach, and just sticking to documenting the necessary ...
3
I began building an engine using WWF WCF several months ago. I do not know how complex your rule base is, but ours was pretty large. When you have the potential for something like 40,000 branches, WWF is not a good fit. As an alternative, I ended up building an engine that used logic exception tables in SQL. The rows would store the basic values, as well as ...
3
If I were to do this I would create a Domain Specific Language to express the rules, and maybe give the biz types a UI to modify it if requested. Then use a functional language (like Haskell, Lisp or Erlang) to evaluate the rules.
If massive parallelism was required I would go with Erlang which does concurrency very well. Using Erlang would scale well from ...
3
break it down:
get general outline first and create a prelim design of the simple version
then start adding complexities in line with business logic but keep the changes small and compatible with expected updates (but keep consistency always)
(this is a top-down approach)
shut the domain expert up and/or interrupt him regularly with questions/remarks ...
3
I actually just recently reworked some code to separate the objects from the data. The reason is that the data is obtained through a separate service, and it is much easier to just pass the raw data to/from the server instead of passing the entire object back and forth and having to deal with validation errors on the server.
For small projects, having ...
3
I think both ways of doing it can have their benefits, but I would look at it from an object oriented or domain driven view: what are the responsibilities of the different classes and objects.
So, I would ask myself this, in your concrete case: should a customer know how to save itself?
To me, the answer would be no: logically to me it doesn't make sense, ...
3
Your coworker is absolutely correct. Choosing Option 1 is a sign of a programmer that has not spend one minute maintaining someone else code and does not care about the likes of technical debt and future maintenance of the code base.
Its just a simple program that is needed to process the input data and create correct data for input into your main program. ...
3
I am a strong believer in keeping business logic out of the database as much as possible. However, as my company's performance developer, I appreciate that sometimes it's necessary to achieve good performance. But I think it is necessary far less often than people claim.
I dispute your pros and cons.
You claim that it centralizes your business logic. On ...
2
I think you're specifically talking about the difference between the ActiveRecord pattern and the Repository pattern. In the former, the entities know how to persist themselves, and in the latter, the repository knows about persistence. I think the latter offers a better separation of concerns.
In a broader sense, if the entities act more like a data ...
2
I wrote an application based on WF (windows workflow foundation). My boss (a DBA) was convinced that WF could perform multi-threading without the need to plan for concurrency. Memory was divided thoroughly, but there were so many problems I can't explain it in just a few paragraphs and it's only slightly related to your question...so I continue.
Ability to ...
2
Typically on a broad encompassing user story that has many facets I try to get the most general example of the story, and then for specifics I create child user stories that inherit from it. Many Agile project management tools like RallyDev allow you to do this easily and I find it makes sense.
Registering new books is broad, so perhaps there are 10 other ...
2
I've seen developers write scenarios; testers write scenarios and even a product owner write scenarios. I've also had conversations explicitly designed to bring out scenarios - "Given <this other context>, when what should happen then?" - and written down the words the business use.
The best results I've had were from having a conversation with the ...
2
Your may problem try to code in terms of decision tree or decision table
Also, there is posts into Chris Smith's blog about decision trees:
Awesome F# - Decision Trees – Part I and
Awesome F# - Decision Trees – Part II
Only top voted, non community-wiki answers of a minimum length are eligible
