| Abstract | U ovom radu obrađuje se tema oblikovanja vođenog domenom koju je, u istoimenoj knjizi, osmislio i opisao Eric Evans. Principi oblikovanja vođenog domenom ilustrirani su na primjeru sustava za oblikovanje i praćenje rasporeda sati na fakultetu. Kako bi mogao izgraditi softver koji obavlja korisne aktivnosti, razvojni tim mora biti upoznat s poslovnom domenom tih aktivnosti. Ta domena je često kompleksna i strana razvojnim inženjerima. Potrebno je u razgovoru sa stručnjacima domene procesirati to znanje domene i stvoriti jedan model domene koji će sadržavati znanje o domeni i predstavljati naputak za oblikovanje sustava. Razvijanjem modela razvija se i sveprisutni jezik koji služi kao zajednički jezik između stručnjaka domene i razvojnog tima te kao standardni jezik unutar samog razvojnog tima. Nakon što se sakupi dovoljno znanja o domeni, potrebno je razvrstati objekte domene na entitete i vrijednosne objekte, a procese definirati kao servise. Objekti koji se pojavljuju u grupi, unutar koje postoje invarijante koje uvijek moraju biti zadovoljene, grupiraju se u agregate. Stvaranje agregata i kompleksnih objekata delegira se tvornicama. Pronalazak i dohvat ranije stvorenih objekata vrši se preko repozitorija. Tijekom razvoja često se dođe do novih spoznaja o domeni ili do otkrića drukčijeg dizajna koji omogućava da kôd bolje opisuje domenu. U oba slučaja treba refaktorirati dijelove sustava sukladno novim spoznajama i otkrićima. Koncepte koji su izraženi implicitno unutar koda treba izraziti eksplicitno, dijelove dizajna koji su nezgrapni treba preoblikovati tako da budu gipkiji, podložniji izmjenama, s manje međuovisnosti. To se postiže korištenjem tehnika kao što su sučelja koja otkrivaju namjenu, funkcije bez popratnih posljedica, utvrđivanja (assertions), konceptualne konture, samostojeće klase, zatvorenost operacija i deklarativno oblikovanje. U velikim sustavima, u kojima postoje različiti modeli za isto područje domene, potrebno je paziti da očuvamo integritet modela na razini čitavog sustava. Područje domene zna postati toliko veliko i kompleksno da moramo izdvojiti jezgru domene, kako bismo razlikovali srž sustava od njegovih potpornih elemenata. Ponekad je korisno nad sustavom velikih razmjera definirati određenu strukturu kako bismo jednostavnije mogli razumjeti ulogu dijelova u cjelini. |
| Abstract (english) | This thesis is about domain driven design, a design approach that Eric Evans describes in his book of the same title. The principles of domain driven design have been illustrated on an example of a system for designing and monitoring academic timetables. In order to make a software that does some useful activities, a development team must have knowledge about the underlying business domain. That domain is often complex and unfamiliar to the developers. Developers must engage in knowledge crunching activities with domain experts in order to create a model that contains rich domain knowledge and dictates the design of the software. As a result, a ubiquitous language is developed that is used as a common language between developers and domain experts and as a standard language between the developers. After certain knowledge is obtained, domain objects are specified as entities or value objects and operations are defined as services. Some objects come in groups and have invariant that always need to be satisfied. They are formed in aggregates. Creating aggregates and complex objects are delegated to factories. Finding and retrieving objects that have previously been created and stored is done through repositories. During development, refactoring is needed to reflect new insights about the domain or to obtain a design that allows better expression of the domain through code. Implicit concepts must be made explicit, cumbersome parts of the design should be redesigned in a more supple way in order to make it easier to change, with less interdependencies. That is accomplished by using techniques such as intention-revealing interfaces, side-effect-free functions, assertions, conceptual contours, standalone classes, closure of operations and declarative design. In large systems that have several models for the same domain segment we need to focus on maintaining model integrity on system scale. A domain can be so complex and huge that it is hard to distinguish the core domain from its supporting elements. Sometimes, it is useful to impose a certain structure to a large-scale system in order to better understand the roles of the parts of the system in the whole system. |
