While I am trying to discerned the difference between the application logic and business logic I have found set of articles but unfortunately there is a contradiction between them.
Here they say that they are the same but the answer here is totally different.
For me I understand it in the following way:
If we look up for the definition of the Logic word in Google we will get
system or set of principles underlying the arrangements of elements in
a computer or electronic device so as to perform a specified task.
So if the logic is set of principles underlying the arrangements of elements then the business logic should be set of principles underlying the arrangements of the business rules, in other words it means the rules the should be followed to get a system reflects your business needs.
And for me the application logic is the principles that the application based on, in other words, how to apply these rules to get a system reflects your business needs, for example should I use MVC or should not I use?, should I use SQL or MSSQL?, should I handle errors using exception handling or if statment?.
So please could anybody help me to get rid of confusion.
Well there's going to be a few interpretations of this one, but here's mine.
Business logic is the rules that are in place whether your business is computerized or not.
Application logic is how a particular slice of that business is realised.
Take for example an insurance business offering multiple and complex policies. All the conditions, calculations, payment schemes, conditions of offer etc. are 'business rules'. A website that says "enter dob and income to get an instant estimate on our most popular products" would contain application logic as would a back office report for "top 500 earners that didn't buy".
Each is an example of a specific use. Business rules apply but they are constrained and supplemented by other rules (like just these policies).
So typically business rules are rules, application rules are a subset selected and packaged for a purpose.
Application Logic tells how an application is designed and developed. How you have maintained the standards through out the application. Usability, UI, Functionality etc are maintained throughout the application.
Business Logic is how a business is designed and implemented. What are the Business rules, Business Workflows.
Now a days, sometimes Business logic is adjusted as per application logic. And sometimes application logic is injected in Business logic to streamline each other.
SalesForce is an example.
"Application logic" (sometimes referred to as "work logic" in older literature), is the abstract of your source. It's closely tied to the implementation, and not necessarily to the real world problem it solves.
Example 1
You have a deck of cards. Your business logic may contain a step like "sort the cards", focusing on the desired outcome, as in, "whatever you do at this point, the cards need to end up sorted". This makes sense from a business point of view.
Your application logic, on the other hand, will contain something like "use a distribution sort here", which is completely off topic for the business side (it only cares about the output), OR, your code may even do no sorting at all, for example because you store your cards with a bitfield where it's "already sorted". So the point is, a step on the business side don't necessarily correspond to a step in the app logic.
Example 2
You have an elevator. Business rules are like "if we're going downwards and someone below us presses the down button, we stop there". This is an algorithmic step, but from a human perspective. Your application gets this need as a requirement, and... well, in the case of an elevator, you'll need to know the speed, maximum deceleration, distance from caller floor, priorities, other elevator cars' position and a bunch of other factors, and you get a pretty complex app logic just to deliver that simple requirement. And still, both are algorithms. One for the purpose of elevators, and another for the horrible mess beneath. (I'm absolutely amazed by elevators and their software, btw.)
Related
Hey I have an aggregate root with some properties which need to be calculated - totals.
These properties are not saved, but are needed to fill a readDto while seeding and an Event for the EventStore when the aggregateRoot is created or updated.
Is it a good practice to have a COMMON service between the read and the write part, which will calculate these totals and provide them to dtos or events or wherever they are needed ?
to have a COMMON service
It's permissible to use any valid technique you'd normally use to effect the DRY principle (but bearing in mind to temper this with the Rule of three).
Sometimes, this means copying a file of helpers between the write/decision process and a projection service. Sometimes you might even compile those into a single helper library. Sometimes is a piece of code in a dynamic language that can be run against an instance of an event (or series of events being folded) hydrated in the context of the decision process, the projection service or a reader process.
There is no fundamental law that says there must be exactly one thing (a compiled piece of code running as single service) which owns the rule - for starters, what happens if you want to deploy an update to that service without downtime?
In short - there is no hard and fast rule; any such a one size fits all prescriptive recipe would have hundreds of exceptions. A bit like an enterprise wide universal data model ;)
I am not that afraid of breaking DRY principle by using a single service.
My real concern is about if using common read/write stuff is against
the CQRS pattern.
Quite often this can be legitimate - readers and writers both observe the stream of events in order to infer ('fold') a rolling state. Readers may be exposing contextual information which can be used to drive 'users' to formulate commands representing desired actions/state transitions, which necessarily have a degree of overlap. The key thing is that decision making itself should only live on the write side (bu this fits well with the general principle that a command should normally not result in feedback - typically it should be idempotently processable with any validation etc. being a fait accomplit security-driven double check)
And secondly if using logic in the read part is against the CQRS pattern.
One typically agreed no-no is having conditional logic in the fold which maintains the rolling state - this should be simple mechanical accumulation.
For a projection and/or denormalizer which is maintaining an eventually consistent read-only view based on observing the events will often be using overlapping simple projection logic. If that logic gets complex, involves transactions etc., that's a design smell though - if the Events represent what's going on naturally and not contrived, they should tend to be relatively straightforward to map/project - you should really only be 'indexing' them or laying them out in a form appropriate for the given necessities of the reader.
If you're ending up with complex flows in the projection system, that's a sign you probably have multiple different readers and should perhaps consider separate projections to that end (i.e. kinda like the Interface Segregation Principle)
Basically, after hours of researching I still dont get what the Unifying Logic Layer within Semantic Web Stack Model is and whose problem it is to take care of it.
I think this depends on what your conceptualisation of the semantic web is. Suppose the ultimate expression of the semantic web is to make heterogeneous information sources available via web-like publishing mechanisms to allow programs - agents - to consume them in order to satisfy some high-level user goal in an autonomous fashion. This is close to Berners-Lee et al's original conceptualisation of the purpose of the semantic web. In this case, the agents need to know that the information they get from RDF triple stores, SPARQL end-points, rule bases, etc, is reliable, accurate and trustworthy. The semantic web stack postulates that a necessary step to getting to that end-point is to have a logic, or collection of logics, that the agent can use when reasoning about the knowledge it has acquired. It's rather a strong AI view, or well towards that end of the spectrum.
However, there's an alternative conceptualisation (and, in fact, there are probably many) in which the top layers of the semantic web stack, including unifying logic, are not needed, because that's not what we're asking agents to do. In this view, the semantic web is a way of publishing disaggregated, meaningful information for consumption by programs but not autonomously. It's the developers and/or the users who choose, for example, what information to treat as trustworthy. This is the linked data perspective, and it follows that the current stack of standards and technologies is perfectly adequate for building useful applications. Indeed, some argue that even well-established standards like OWL are not necessary for building linked-data applications, though personally I find it essential.
As to whose responsibility it is, if you take the former view it's something the software agent community is already working on, and if you take the latter view it doesn't matter whether something ever gets standardised because we can proceed to build useful functionality without it.
In my admittedly young career I've found myself writing code to support quirky business rules and processes. Inevitably these changes were always in some massively difficult code base and caused many issues. My question has a couple of parts:
While software is a tool for businesses to make their lives easier, at what point do we as developers suggest a change in business process rather than in the software as the "magic bullet" to solve a particular problem.
How do we as developers evangelize a certain level of reverence for the software as well as the difficulty involved in making changes simply to support the quirks of the business?
I understand that these changes in business processes promote our industry, but in an analogy my father would understand: Which is easier, to melt down a hammer to forge a screwdriver to drive screws or to simply use nails since your hammer is already awesome...?
You can look at
Seven Habits of Highly Effective
People
, as there is the sense that you need to develop a sphere of influence large enough to try to change business processes.
Your best bet is to show that you are very competent at your job, and work on developing relationships with people on the business side, so that you can feel comfortable sitting down outside of work to discuss the business process in question.
This is a slow process, but if you try to rush too fast the business will push back, and squash you like a bug. If you read
The Age of Heretics
for example, you will see examples of companies that were too successful in making changes, and the corporation destroyed them.
At the moment your best bet is to make changes, as you can, to have the software be more adaptable, so that if the process changes you can easily adapt to the new rules.
Before you can do anything, you'd better step back and try to understand the business. If they're reacting to change by adapting their processes, that's a GOOD thing. It's when they leave things exactly the same for years that you can forget about them remaining a company. You need to make sure, however, that the change you're responding to won't negatively impact up- or down-stream business processes. Business units don't often do that checking. But, when it all goes to hell, you know who they're going to blame, right? By doing this, you can head those issues off and evangelize, "better ways." Not doing it is a prescription for eternal frustration.
Learn their business before you even think of codifying it.
As for the mechanics:
What I always had my teams write was, "generic software." Some business unit might have needed a way to capture a form and produce a report. Okay, easy enough, right? Wrong. Always consider a request as something*200. Would you want to support 200 such applications, all doing almost the same thing? Not me. Too lazy.
I directed my teams to make a generic form system and use off-the-self or generic reporting mechanisms. And I stressed the use of XML/XSLT for as much as possible (not relying, for example, on Microsoft's easy-bake-oven technologies that seem to break with each new release). Then, when another business unit wanted, "something similar, but with changes," the core was already there - we only needed a new folder, modified XML/XSLT and we were done.
That always - ALWAYS - made those future changes easier to handle. "Need a new field? Change an XML file. Need to change the way a report is produced? Change XSLT. No program changes." Get it? NO program changes. Keep as much as you can OUT of the logic. Even business processes can be represented in XML/XSLT.
In reality, most of the applications you'll come across are the same Programming Wheels (a good algorithm book, by the way) that have been done forever. They'll just be done more poorly by people who didn't understand the business and understood their craft even less.
They're not going to build their business around you or your software, unless you're writing MS DOS for the first time. The second you suggest it, you'll be gone. And... you should be.
One of the most frustrating things any end customer (that is, a customer of your employer or customer) can hear is "the computer won't let me do that". Say, add items to an order after the shipping is calculated, or cancel something before the sales tax has been calculated, or whatever. The software should serve the business. Sure, that means the software has to change a lot, and sometimes it changes so much from where it was that you have to start over. As you grow in experience you will write software that is easier to change, given the unadjustable reality that business process change, laws change, tax codes change, customers change, and so on. Some day you may be a trusted business advisor to your clients. That is unusual early in your career. I'm in that stage now but I'm in my fourth decade of being paid to program. I rarely suggest the business accomodate the software. It takes a lot of judgement to know when that might be the right thing to suggest. And whatever reverence you might feel for your software, do your best to hide it from the folks who pay for it. They see it as a tool to support the real business they're in.
I think there is value in questioning the cost effectiveness of building new solutions to adapt to existing business processes versus adapting business processes to adapt to existing solutions. However, in reality, I have not seen the business consider this angle.
With that in mind, I think the next best thing you can do is to anticipate specific changes that the business might request in the future and develop your solution such that it can adapt to those changes easily.
Unfortunately, this is entirely situation-dependent.
Even with a great deal of experience in business AND software, it is still a complex issue.
As far as your specific questions:
As soon as you see them. What is important is to couch your suggestion in constructive terms. Also using terms relevant to the business (ROI, NPV, etc). And finding ancillary benefits (). So if the software change really doesn't mitigate the business problem, the cost is high and fixing the business process has significant ancillary cost savings, you pose a completely different scenario than just saying "we can't do it because it costs too much".
The software is owned by the business - it isn't owed any more or less reverence than anything else the company owns of similar value.
When facing escalating business rules complexity in relation to the current form of the software, try considering Aspect-Oriented-Software-Development, in order to achieve better modularity and separation of concerns. This way, new or changing business rules, as they appear, may be integrated in your existent code base as plug-ins to only those modules that need them, not being necessary to rewrite large amounts of unrelated code.
The idea is that after all, a lot of business rules come from specific legislation, and it's the responsibility of the business, transmitted to the software as well, to implement and adapt. I personally believe that the lack of will to follow specifications due to perceived difficulty is what lead most web browsers to lag more or less behind web standards - altering the rules was a temporary workaround that has lead in time to a far greater accumulated cost by supporting each browser's particular quirks. Try to implement new business rules as fast as they appear or they change - failing to do so leads to accumulative lacks of support for new functionality and ultimately render your software deprecated.
That's kind of like the role/strength of the CIO. If the IT side can convince the business side that it would be easier/cheaper/cost effective to change the business process than the code, than you have a point. Otherwise, the quirky business practice may be more valuable than you think. I also doubt that you are making it clear that if you spend time on the quirky problem, you won't deliver the needed features on time (good luck with that).
If technologists had their their way, the GUI and the mouse/pointer would never have made it out of the lab. For everyday users, they're here to stay.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm going through all sorts of WPF documentation, and I'm feeling unnecessarily confused. The term 'business logic' is scattered throughout it, as if everyone should know what it is.
I can see what business logic is, according to this question here:
What exactly consists of 'Business Logic' in an application?
But where did the term come from? Why is it called 'business logic' and not, say, 'core logic' or 'main algorithms' or any other more generic terms? Very few of the programs I write have anything to do with 'business logic', and when I think of 'business logic' I think of things handling credit card transactions, customer database maintenance, and the like. In other words, things that relate to a fraction of the entirety of computer science. When I write an imaging application, there is no 'business' involved, no customers, no money-based transactions, nothing of the sort. So saying that I have 'business logic' really confuses me, since I'm not conducting business, I'm processing images.
For the same reason that the end of a gun which the bullets come out of is called the “business end”. It's where the primary action happens.
If you were a professional graphic designer, there certainly would be business involved with using your imaging application - your job is your business!
So "business logic" refers to the parts of the code that define how the user conducts his business (in this case, manipulating images).
Don't forget that back in the day, all software was "business software" - no-one could afford the expensive equipment and skills required to write software for anything other than business purposes. It if didn't make money or save money for a business, it didn't get written.
Not sure, but I think the term should be replaced with domain logic instead.
You could have called it "core logic", but I believe that the first (well-known) multi-tiered apps were actually written for insurance or banking, hence the term "business logic". From there, the pattern took form, and the naming stuck.
Had the first multi-tiered apps been a research project or something, it probably would have been called "core logic".
The origin of the term is in business software, where business specific rules were separated in their own modules. That merely got transferred to all the other software.
When I write an imaging application, there is no 'business' involved, no customers, no money-based transactions, nothing of the sort. So saying that I have 'business logic' really confuses me, since I'm not conducting business, I'm processing images.
Furthermore, much of the advice about presentation and data starts going south too, as operations such as effects and filters which would be extras in a 'presentation layer' in a business application are the core of yours.
"Visualisation", "Engine" and "Persistent storage", are quite common names for the layers in the simulations I tend to work on. There's no problem using names meaningful in your domain. But then I get confused about all the job ads for SAS programmers, as that means something else in a UK defence setting; if you want to talk to business people you have to translate for them.
Thinking about early computer systems, like credit card processing, there are two large parts to the code, the parts doing the io, talking to the back-ends, tape, etc, and the parts doing the logic of the business, rules like, is the card valid, has the limit been exceeded.
Another way to think about it, it's the things a business person would say are the 'rules' to capture.
Business logic is that part of an application where "how" is should work is determined by someone other than the programming team. Usually it is the code that does what the customer wants to get done. The term generally only applies to in house software built for a non-IT group.
I think many times its sarcastic, because business logic is not always logical. its done certain way only, because business wants it that way - many times its not the best way. you can fight with them and (if youre lucky) make them see the light or just accept the fact that its business logic and be ready to change it when they realize they made mistake.
It is a term used mainly for Line of business applications & one more way people know of it is CRUD app (create, read, update, delete).
I think it means the class(es) contain the logic of how the business process works for given business process(es).
I think I agree with DVK - IIRC, at the time, the whole Data->Logic->Presentation layer thing was an "enterprise" (basically: business) software buzzword.
Now that every goddamn web page should be three-tiered, it's much more common.
You also have to remember that while there's a lot of code other than business code, the amount of business code is huge, and a huge business (har har) as well. It's not really surprising that some terms originated there.
I think nmr is quite correct. I'm teaching my HCI software engineering course, and I need to encourage students to stop thinking of "Business Logic" and think more about MVC.
Quite often, their previous professors would tell them that,
"Underneath the HCI is the BIDness Logic"
Can we please LOSE the business logic? Since software rarely has NO user interface,
we can say, for the rest of the software, there is the View, the user Control, and the Model.
And there will be message passing between these three entities. Which are, by the way, "output", "input"/"state". Just as Turing (and Church) had taught us.
So... let's lose 'the bidness logic'
Just like the pretty you goes to the bathroom to do your business, your pretty GUI goes to the logic to do its business..
(Sorry, couldn't resist :) )
I was reading Code Complete (2nd Edition), and came across a quote in the margin on page 87 by Bertrand Meyer.
Ask not first what the system does; ask WHAT it does it to!
What exactly is the point Mr. Meyer is trying to get across here. I have some rough ideas, but I would like to make sure I really understand.
... So this is the second fallacy of teleology
- to attribute goal-directed
behavior to things that are not
goal-directed, perhaps without even
thinking of the things as alive and
spirit-inhabited, but only thinking, X
happens in order to Y. "In order to"
is mentalistic language, even though
it doesn't seem to name a blatantly
mental property like "fearful" or
"thinks it can fly". — Eliezer Yudkowsky, artificial intelligence theorist
concerned with self-improving AIs with stable goal systems
Bertrand Meyer's homily suggests that sound reasoning about systems is grounded in knowing what concrete entities are altered by the system; the purpose of the alterations is an emergent property.
I believe the point here is not on what the system does, but on the data it operates on and what those operations are.
This provides two major thinking shifts:
You think of the data and concepts first
You think of operations on that data
With those two "baselines" you will better prepared to organize a system to achieve your goals so that operations on data are well understood and make sense.
In effect, he is laying the ground work to be able to write the "contracts" on the code you write.
From Google search it picked up Art Gittleman's Computing With C# and the .Net Framework:
Bertrand Meyer gives an example of
payroll program, which produces
paychecks from timecards. Management
may later want to extend this program
to produce statistics or tax
information. The payroll function
itself may need to be changed to
produce weekly checks instead of
biweekly checks, for example. The
procedures used to implement the
original payroll program would need to
be changed to make any of these
modifications. Meyer notes that any of
these payroll programs will manipulate
the same sort of data, employee
records, company regulations, and so
forth.
Focusing on the more stable
aspect of such systems, Mayer states a
principle: "Ask not first what the
system does: Ask WHAT it does to!";
and a definition: "Object-oriented
design is the method which leads to
software architectures based on
objects every system or subsystem
manipulates (rather than "the"
function it meant to ensure)."
We today take UML's class diagram and other OOAD approach for granted, but it was something that was "discovered" along the way.
Also see Object-Oriented Design.
My opinion is that the quote is meant as a method to find good abstractions in your software. The text next to this quote deals with finding real-world objects to design your classes.
An simple example would be something like this:
You are making software for a bank. Because your software is working with bank accounts, it should have a class for an account. Then you start thinking what properties accounts have and the interactions you can have with accounts.
Of course, this quote makes more sense if the objects you are trying to model aren't as clear as this case.
Fred Brooks stated it this way:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."
Domain-Driven design... Understand the problem the software is designed to solve. What "domain" entities, (data abstractions) does the system manipulate ? And what does it do to those domain entities?