DDD гэж юу вэ, хэрхэн ашиглах талаар

DDD гэж юу вэ ?

Domain-driven design гэдэг нь тухайн бизнесийн салбарын хүчин зүйлүүд (бизнест мөнгө авчирч байгаа тэдгээр зүйлүүд) дээр төвлөрч хөгжүүлэлтээ хийх буюу технологи болон бусад зүйлийг хоёрдугаарт тавин бизнесийг дэмжих гэсэн санаа.

Domain-driven development буюу тухайн бизнесын салбарын ухагдахуунууд, тэдгээрийн хоорондын уялдаа холбоо, шаардагдах нарийн дүрэм журам, үүдэн гарах процесс зэргийг програмд тусгаж, тэдгээрийг хөгжүүлэлт хийгдэх аливаа технологиос тусгаарласнаар хөгжүүлж буй програм маань бизнесээс шаардаж буй нарийн уялдаа холбоо, дүрэм журамтай яг таг тохирч, хичнээн ч нарийн төвөгтэй салбарыг компьютерт загварчилж, ирээдүйд урт хугацаанд бизнесийг дэмжин, тогтвортой ажиллах боломжийг бий болгодог тогтолцоо (фраймворк) юм.

Хэрхэн ашиглах вэ ?

Хэрэв та аливаа нэг том салбарын програм хангамжийн төсөл дээр ажилладаг бол тухайн салбарын нарийн дүрэм журам, ойлголтуудыг тодорхой түвшинд мэдэж, суралцахаас өөр аргагүй болно. Ингэж суралцах явцдаа та өөрийн сурч, ойлгосон зүйлсээ програмдаа тусгаснаар таны хөгжүүлж буй програм тань тухайн салбарт илүү ойртож, биеждэг. Хэдийгээр та салбарын мэргэжилтнээс зөвлөгөө, нарийн дүрэм журмыг суралцаж програмдаа тусгах боловч, мэргэжилтний хэлсэн бүх зүйл бүхэн таны програмд яг тэр хэвээр тусгагдах боломжгүй юм. Энэ нь юу гэсэн үг вэ гэхлээр, хэдийгээр мэргэжилтэн салбарынхаа ухагдахуунуудыг сайн мэдэх авч, яг тухайн бүхэл бүтэн системийн нарийн зүй тогтол, уялдаа холбоог нэг бүрчлэн бүрэн гүйцэт мэддэг байх нь ховор юм.

Системийг компьютерт програмчлахад мэдлэгээс гадна хөгжүүлэгдэх програмын технологиос хамаараад, уг системийн модель нь бүрэн гүйцэт програмд тусгагдах нь мөн тийм ч амар биш.
Тиймээс та уг системийг компьютерт хэрхэн модельжуулж, системчлэн хөгжүүлэхэд тодорхой арга барил, амьдрал дээрх туршлага заавруудаас суралцах шаарлага тулгарна.

Domain driven design нь эдгээр шаардлагууд дээрээс бий болсон ба таньд аливаа том системийг хөгжүүлэхэд нь туслах болно.

Доорх ойлголтууд нь DDD-ын үндсэн ойлголтууд бөгөөд илүү дэлгэрэнгүй мэдэхийг хүсвэл та доорх “Холбогдох ном зүй” хэсэгт дурьдсан номнуудаас мэдэх боломжтой.

  • Domain model
    Энэхүү ойлголт Domain Driven Design -ны зүрх нь юм. Моделийн үүрэг нь тухайн бизнесийн салбарын юу нь энэхүү бизнесийг бусдаас ялгаатай, үнэ цэнэтэй болгож байгааг агуулах юм.
  • Ubiquitous language
    Domain model (бизнесийн салбарын загвар) -ыг илэрхийлэхэд хэрэглэгдэх тэрхүү яриа, нэршил, ойлголтууд юм.
    Үндсэн зорилго нь салбарын мэргэжилтэн, програм хөгжүүлэгч нарын хоорондын харилцах ярианы ойлголтуудын нэршлүүдийг нэг болгож хоорондын үл ойлголцолыг багасгах.
    Хөгжүүлж байгаа багийн гишүүд, салбарын мэргэжилтэн нар цугтаа ярилцаж байж энэхүү нэршлүүдийг хамтарч бий болгоно. Мөн хоорондоодын харилцаандаа зөвхөн эдгээр нэршил, ойлголтуудыг ашиглах ба өөр зөрүүтэй ойлголт болон  хэн нэгнээр дамжин харилцах явдал гарах ёсгүй. Ингэснээр хоёр талын харилцан яриа илүү хурдан, үр дүнтэй болж хоёр тал бие биенээ илүү сайн ойлгож, модель маань илүү биежиж, жинхэнэ утгаараа бизнесээ дэмжих болно.
  • Bounded-Context
    Аливаа том систем нь хэд хэдэн дэд хэсгүүдээс бүрддэг. Тиймээс систем нь тэдгээр дэд системүүд нь хоорондоо харилцан мэдээлэл солилцох зарчимаар ажилладаг. Тухайлбал аливаа нэг компани доторх алба, тэнхмийн адилаар систем маань мөн дотроо төлбөр тооцоо, бүтээгдэхүүн гэх мэтийн тодорхой, биеэ даасан нэгжүүдээс тогтно.
    Bounded-context нь энэхүү дэд системийг төөлөлөх ба хэрхэн яаж том системийг олон жижиг бие биенээсээ хамаарал багатай үндсэн дэд хэсгүүдэд хуваах, тэдгээрийн хоорондын харилцах аргыг зохицуулж, шийдэхэд тань тусална. Ихэвчлэн эдгээр дэд хэсгүүд нь мөн өөрийн гэсэн Ubiquitous language-тай байдаг бөгөөд тодорхой ойлголтууд нь бусдаасаа нэршлийн хувьд ижил байдаг ч утга, агуулгын хувьд ялгаатай байж болно.
  • Context mapping
    Энэхүү ойлголт нь системийн дэд хэсгүүдийн хоородын хил хязгаарыг тодорхойлж ил тодорхой болгох зорилготой загварчлалын арга юм. Хэрэв системийгганцхан үндсэн хэсгээс бүрдэх байдлаар загварчилбал удаан хугацаанд цаашид тордон авч явахад маш хэцүү болж, эцэсдээ хэн ч ойлгохын аргагүй маш төвөгтэй зүйл болж хувирдаг. Тиймээс системийн зүй тогтлыг зөв олж чадвал өөр хоорондоо тодорхой байдлаар харилцах дэд хэсгүүдэд хувааж болдог. Context-mapping нь хэрхэн тэдгээр зүй тогтол, харилцааг олоход тань тусална.
  • Domain object
    Бизнесийн салбарын чухал ойлголтуудыг төлөөлөх объект. Энэхүү объект нь амьд биологийн системийн молекулийн адилаар бусад объектой харилцахдаа юуг хийж болох болохгүйг өөртөө агуулах ба ингэснээр салбарын чухал ойлголтыг жинхэнэ утгаараа төлөөлж ажиллах учиртай.
  • Entity, Service, Repository
    Эдгээр нь DDD-ын стандарт ойлголтууд юм.
    Entity нь ямар нэгэн нэр, хаяг, дугаараар таньж болох нэр үгээр илэрхийлэгдэх ойлголт юм. Жишээ нь: Машинийг түүнийг бүртгэлийн дугаараар олж болох учир “Car”, хэрэглэгчийг регистрийн дугаар, паспортын дугаараар нь болж болох учир “User” гэх мэт тодорхойлж болно.
    Service нь хэрэв объект нь ганцаараа хийж чадахгүй, заавал бусадтай харилцах шаардлагатай бол Service -ыг ашигладаг. Энэхүү сервис нь хэзээ ч ашиглахад ижил төрлийн үр дүнг өгдөг, өөртөө ямар нэгэн тодорхой оршин байдлыг хадгалдаггүй гэдгээрээ онцлогтой класс юм
    Repository хэрэв Entity нь өөрийн тухайн үеийн оршин байдлыг хадгалах шаардлагатай бол түүнийг байнгын санах ойд хадгалахад шаардлагатай. Энэхүү байнгын санах ой гэдэгт ихэвчлэн өгөгдлийн бааз ордог. Жишээлбэл хэрэв хэрэглэгч хаягаа солих, нэрээ өөрчлөх гэх мэтийн өөрчлөлтүүдийг систем нь заавал байнгын санах ойд хадгалах шаарлагатай.
    Repository нь бизнесийн чухал ойлголтууд (domain object), өгөгдлийн сангын хооронд гүүр болон ажилладаг.
  • Aggregate
    Зарим нэг салбарын ойлголтууд үндсэн төлөөлөгч хэсэг болон түүнд хамаарах нэгжүүд гэсэн бүтэцтэй байдаг. Жишээлбэл: Худалдан авсан захиалга (Purchase Order) болон түүнд орох захиалсан бараанууд (Order items) юм.
    Иймэрхүү бүтэц бүхий ойлголтыг “Aggregate” -ээр төлүүлж, бизнесийн дүрэм, шаардлагуудыг гүйцэтгэхэд бүхэлд нь нэг гэж үздэг. Жишээлбэл: худалбан авалтын захиалга хийгдлээ гэвэл захиалгад багтах нэгжүүд мөн хийглээ гэсэн үг.
  • Domain event
    Бизнесийн салбарын чухал үйл ажиллаа төлөөлнө. Жишээлбэл үүнд:
    хэрэглэгч захиалга хийлээ, зээлийн карт нээлгэлээ, зээлийн төлбөр хийгдлээ гэх мэт тухайн бизнесийн салбарын чухал үйл явцуудыг төлөөлдөг ба ихэвчлэн өнгөрсөн цаг дээр илэрхийлэгддэг. Систем нь эдгээр үйл явцад харгалцах дүрэм журмыг шалгаж, шаардагдах процессуудыг цааш дэд хэсгүүд болон бусад сонирхож буй дэд ангиудад тараадаг. Энэ Domain event нь ихэвчлэн системийг өөр хоорондоо хамаарал багатай дэд хэсгүүдэд хуваахад чухал хүчин зүйл нь болдог. Жишээлбэл: Хэрэглэгч төлбөрөө төллөө гэсэн үйл явцад төлбөр тооцооны дэд систем гүйлгээг хариуцан хийх бол, барааны агуулахын дэд систем худалдан авсан барааг агуулахын бэлэн байгаа барааны хэсгээс хасаж, бусад холбогдох тооцооллыг хийнэ гэх мэт.
    Мөн бизнес нь энэхүү үйл явцуудыг хөтөлж, тэмдэглэж явах юм бол жилийн эцэст гаргах судалгаа болон бусад маркетингийн зорилгоор ашиглах нарийн мэдээллийг мөн боловсруулах боломжтой болдог.

Амьдрал дээрх жишээнүүд

Төслийн програмын үндсэн бүтэц нь ерөнхийдөө доорх байдалтай байдаг:

src/
     Application/
     Domain/
            Model/
                  Entity/
                  ValueObject/
            Service/
            Repository/
            Event/
            EventListener/
            Command/
     Infrastructure/

Бусад жишээнүүд:

Анхаарах зүйлс

Хэдийгээр энэхүү DDD загварчлалд маш олон давуу талууд байдаг боловч доорх зүйлсийг анхаарвал зохино:

  • Жижиг төсөл дээр DDD хэрэглэвэл ихэвчлэн нилээдгүй их цаг, хөлс хөдөлмөр шаарддаг тул ерөнхийдөө зайлс хийвэл зохино.
  • Хэрэв хөгжлүүлж буй салбарын мэргэжилтэнтэй хамтарч ажиллах боломжгүй, салбарын нарийн уялдаа холбоог мэдэх боломжгүй бол загварчилахад илүү төвөгтэй бөгөөд DDD хэрэглэсний ашиг нь гарахгүй
  • Хэрэв хөгжүүлж буй төсөл тань биснесийн нарийн уялдаа логик,  дүрэм журам зэрэг нарийн төвөгтэй биш, харин илүү техникийн тал нь давамгайлсан бол DDD хэрэглэх нь мөн тийм ч үр дүнтэй биш байх.

 

Холбогдох ном зүй:

  • Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

    Энэхүү ном нь нарийн, төвөгтэй системийг хэрхэн системчлэн задлан шинжилж, олон жилийн туршлага дээрээс бий болсон арга техникийн тусламжтайгаар системчлэн ойлгомжтойгоор хөгжүүлэх арга техникүүдийг тайлбарласан анхны ном юм.

 

 

  Гүүгл Докоор үзэх

https://docs.google.com/document/d/1KBdis6RIlZf2Fh3I7i9Ar3iPVn6EqGLykqwZ-26BqYA/edit?usp=sharing

Advertisements

Хариулт үлдээх

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Өөрчлөх )

Twitter picture

You are commenting using your Twitter account. Log Out / Өөрчлөх )

Facebook photo

You are commenting using your Facebook account. Log Out / Өөрчлөх )

Google+ photo

You are commenting using your Google+ account. Log Out / Өөрчлөх )

Connecting to %s