Бизнес-логика: Бағдарламалық қамтамасыздағы іскерлік ережелер

Кіріспе

Компьютерлік бағдарламалық жасақтамадағы түсінік. Компьютерлік бағдарламалық жасақтамада бизнес-логика немесе домендік логика – деректерді қалай жасауға, сақтауға және өзгертуге болатынын анықтайтын нақты әлемдегі бизнес ережелерін кодтаушы бағдарламаның бөлігі. Ол дерекқорды басқарудың, пайдаланушы интерфейсін көрсетудің, жүйелік инфрақұрылымның немесе бағдарламаның әртүрлі бөліктерін байланыстырудың төменгі деңгейдегі мәліметтерімен айналысатын бағдарламалық жасақтаманың қалған бөлігінен ерекшеленеді.

Бизнес-логика және деңгейлер/қабаттар

Бизнес-логика бағдарламаның кез келген бөлігінде орналасуы мүмкін. Мысалы, белгілі бір форматтағы мекенжай үшін, бизнес-логикада көрсетілген өрістерге сәйкес келетін бағандары бар деректер базасының кестесі құрылып, жарамсыз деректер енгізілмеуін қамтамасыз ету үшін типтік тексерулер қосылуы мүмкін. Бизнес-логика жиі өзгеріп отырады. Мысалы, онлайн-саудагер жаңа елге тауар жеткізуді бастағанда, қабылданған мекенжай форматтарының тізімі өзгеруі мүмкін. Сондықтан, бизнес-логиканы іске асыратын кодты оқшауландырып, байланысын азайту пайдалы деп есептеледі. Бұл бизнес-логикаға өзгерістер енгізу кезінде кодтың тек бір бөлігінде шағын түзетулер жасау қажеттігін қамтамасыз етеді. Алшақ, бірақ тығыз байланысты код бағдарламашының қажетті өзгерістердің барлығын жасамауына және жүйенің бір бөлігін жіберіп алуына, соның салдарынан қате жұмыс істеуіне әкелуі мүмкін. Көп қабатты архитектура осы ажыратуды бизнес-логикалық қабатты құру арқылы формалдайды, ол деректерге қол жеткізу қабаты немесе қызмет қабаты сияқты басқа қабаттардан бөлек болады. Әр қабат басқа қабаттардағы код туралы тек қана қажетті тапсырмаларды орындау үшін жеткілікті біледі. Мысалы, модель-көрініс-бақылаушы (MVC) парадигмасында бақылаушы және көрініс қабаттары мүмкіндігінше кіші болуы мүмкін, ал барлық бизнес-логика модельде шоғырланған. Электрондық коммерция мысалында, бақылаушы төлем кезегіндегі веб-беттердің тізбегін анықтайды және электрондық пошта, мекенжай және төлем туралы ақпараттың бизнес-ережелерге сәйкес келетінін тексеруге жауапты (бұл дерекқорға немесе төменгі деңгейдегі деректерге қол жеткізу кодын жүктемейді). Басқа парадигмалар да қолданылуы мүмкін. Мысалы, салыстырмалы түрде қарапайым бизнес-бірліктері бар жағдайда, жалпы көрініс және бақылаушы деректер базасының нысандарына қол жеткізе алады, олар қабылдайтын форматтар мен мүмкін өзгерістер туралы барлық қажетті бизнес-логиканы қамтиды (бұл деректер базасының моделі деп аталады). Кейбір қабатталған жүйелер жеке қосымша қабатын немесе қызмет қабатын пайдаланады, немесе бизнес-логикалық қабатты олардың бірімен бірдей деп есептейді.

Business logic could be anywhere in a program. For example, given a certain format for an address, a database table could be created which has columns that correspond exactly to the fields specified in the business logic, and type checks added to make sure that no invalid data is added. Business logic often changes. For example, the set of allowable address formats might change when an online retailer starts shipping products to a new country. Thus it is often seen as desirable to make the code that implements the business logic relatively isolated, or loosely coupled. This makes it more likely that changes to business logic will require a small set of code changes, in only one part of the code. Distant but strongly coupled code also creates more of a risk that the programmer will only make some of the necessary changes and miss part of the system, leading to incorrect operation. A multitier architecture formalizes this decoupling by creating a business logic layer which is separate from other tiers or layers, such as the data access layer or service layer. Each layer "knows" only a minimal amount about the code in the other layers—just enough to accomplish necessary tasks. For example, in a model–view–controller paradigm, the controller and view layers might be made as small as possible, with all the business logic concentrated in the model. In the e commerce example, the controller determines the sequence of web pages in the checkout sequence, and is also responsible for validating that email, address, and payment information satisfy the business rules (rather than leaving any of that up to the database itself or lower level database access code). Alternative paradigms are possible. For example, with relatively simple business entities, a generic view and controller could access database objects which themselves contain all the relevant business logic about what formats they accept and what changes are possible (known as the database model). Some tiered schemes use either a distinct application layer or a service layer, or consider the business logic layer to be the same as one of those.

Құралдар мен әдістер

Бизнес-логиканы бизнес-ережелерді басқару жүйесі (BRMS) арқылы процедуралық кодтан бөліп алуға болады. Бағдарламалық жасақтаманы әзірлеудің бизнес-ережелерге негізделген тәсілі BRMS-ті пайдаланады және бизнес-логиканы басқа кодтан күрт ажыратады. Пайдаланушы интерфейсін басқару жүйелері – бизнес-логика мен басқа код арасындағы қатаң бөліністі қамтамасыз ететін тағы бір технология. "Сиқырлы түйме" – "анти-үлгі" саналады: бұл жағдайда бизнес-логиканы оңай қолдауды қиындататын қолайсыз шектеулер тудыратын тәсіл. Домендік модель – бизнес-ережелеріне қажет деректерді сақтау түрлерінің абстрактілі бейнесі.