The heart of an enterprise application is the business logic that implements the business rules.
In a
microservice architecture the business logic is spread over multiple services. Some external
invocations of the business logic are handled by a single service, such as web based self storage
software. Other, more complex requests, are handled by multiple services and sagas are used to
enforce data consistency. In this article, I describe how to implement a service’s business logic.
Business logic organization patterns
The core of a service‘s its business logic. But as figure 1 shows, a service also
consists of one or more adapters. It has inbound adapters, which handle requests
from clients and invoke the business logic. It typically has outbound adapters, which
enable the business logic to invoke other services and applications.
This service consists of the business logic and the following adapters:
REST API adapter, which exposes an HTTP API.
Inbound message gateway, which consumes messages from a
message channel.
Database adapter, which accesses the database
Outbound message adapter, publishes messages to a message
broker
Sitting at the core of the service is the business logic, which is typically the most
complex part of the service and it’s invoked by the inbound adapters. The business
logic invokes the outbound adapters to access the database and publish messages.
Business logic basically consists of 2 broad categories: validation and flow.
Business logic says that qty 1 must be greater than or equal to qty 2 -- for
example, number of items to purchase must be less than or equal to number
of items in stock.
In one application, the business folks will say this is a business rule, and so
you write code to enforce this business logic(validation). Another application
will say that if the number of items ordered is greater than the numbers of
items in stock, to accept the order and then to place your own order for the
difference plus 20%, and so you will write this business logic(flow).
CRUD is simply getting data in and out storage and changing it. Business
logic determines what you do with that data and what transformations you
are allowed to make to it. Is your customer born in the future, under 5, from a
certain geographical area (discounts for locals/visitors). CRUD is simple,
knowing that you can get a child tax credit only if the child lived with you for
more than half of the time it was alive in the calendar year NOT just more
than 6 months, is more
Question:I'm working with web development since 2009, when I started with PHP. When I moved to
ASP.NET I've heard a lot about DDD and OOAD where a lot of focus is given to this "business logic"
and "business rules". The point is that all the apps I've developed until now were all about CRUD
operations and I've never seen these things in practice.
Answer:I simply can't imagine what those things can really be in practice. So, what really is this
business logic and how this fits into an app? I know these are implemented as methods in domain
models, but what those methods could possibly be, and where in the application they could possibly
used?
CRUD is an acronym that stands for Create, Read, Update and Delete. Those
are the four basic operations that you can perform on a database tuple. But
there's always more to business applications than creating, reading, updating
and deleting database records.
Let's start with some basic definitions, and then look at a couple of examples
and see how those definitions map to the examples, and how they map to
actual software.
Business logic or domain logic is that part of the program which encodes
the real-world business rules that determine how data can be created,
stored, and changed. It prescribes how business objects interact with one
another, and enforces the routes and the methods by which business objects
are accessed and updated.
Business Rules describe the operations, definitions and constraints that apply
to an organization. The operations collectively form a process; every business
uses these processes to form systems that get things done.
Now, let's work with some examples.
Transferring money from one checking account
to another
First, what are the things that you need to know (input)?
The identity of the person making the transfer
The amount of money to be transferred
The source checking account number
The target checking account number
What are some of the "business rules" that must be applied?
The person making the request must have the authority to do so.
The transaction must be atomic.
The transaction may have reporting requirements to the
government, if it is over a certain amount
By "atomic," I mean that the transaction must completely succeed or it must
completely fail. You can't have account transactions where money is taken
out of one account without arriving in the other (money disappears), or
money is deposited into an account, but not debited from another account
(money magically appears from nowhere).
Ordering something from Amazon.
What do you need to know?
The identity of the person ordering
Shipping information
Billing information
Method of Payment
Amount and quantity of each item to ship
How to ship (overnight, slow boat or super saver)
State Tax Rate
What happens after the order is placed?
Items are pulled from stock
On hand quantities are debited
Items are packaged for shipment
Out of stock items are backordered
Items that drop below minimum quantities are ordered
One shipment or two?
An invoice/shipping list is printed, and placed with the order
