Domain Driven Architecture for Domain Experts Knowledge - IRD India

Domain Driven Architecture for Domain Experts KnowledgeRepresentation in Software Design and Development1 Kalashankar & 2 N.N.S.S.R.K. Prasad1IT Consultant, Logica, 124-125, Divyasree Technopolis, Yemlur, Bangalore - 560 037, India2 Group Director (Electromagnetic &Optical Systems), ADA, PO:1718, Vimanapura Post, Bangalore-560017, IndiaE-mail : kba.shetty@gmail.com, nnssrkprasad2007@gmail.comAbstract – In order to represent, understand the complexsoftware projects in terms of customer words is onlythrough Domains Model Architecture. The domain modelspeaks about customer needs, essentials; requirements andit also contribute to develop the system with more robust,reliable and understandable with less cost and lesscomplexity. This can be achievable through Model DrivenArchitecture (MDA) and Model Driven SoftwareDevelopment initiatives, have brought back the idea ofgenerating artifacts from models utilizing Domain SpecificLanguages and are constantly gaining momentum inindustrial environments.The IT Industry has been extensively contributing indiversified approach, so to talk; real challenges of complexsoftware projects is not technical realization, but theadequate conversion of the business process itself,knowledge representation of domain expert and thedemands of the professional user. The Domain DrivenDesign (DDD) realm has proven to be very helpful inconstructing healthy and sustainable software [1]. In thispaper we compare and discuss the domain modelcomponents, definitions, domain expert knowledgerepresentation, domain layer architecture and consideringa detail study on one particular domain architecture toexplain the complexity while using the domain entities.Keywords – Agile Model, Domain Objects, EMF, SatelliteDomain, Scrum Model, UML Model.framework support. They are implemented as Plain OldJava Objects (POJO's). The business ruleimplementations do rely on some classes of the Springframework, but they are implemented as separateclasses. The domain model classes are not in any waydependent on them. In other words the heart of the DDDis Model and we start developing our application withdrawing our model. Model and Design we create shouldshape each other, Model should represent knowledge tothe business and it is language our team speaks.Focus on the Domain ModelThe designers and developers can finally focus onthe domain model. They design the technical domainmodel; they add hand-written code supplementing theresulting generated code. All the rest – the layeredarchitecture, the technologies used, etc. is taken care ofby the generator provided.II. LITERATURE SURVEYUbiquitous Language representation for satellitedomainI. INTRODUCTIONThe Domain Models in Software DevelopmentThe domain model is essential in software designand development; it reflects the understanding of aparticular domain using classes, attributes, relationshipsand collaboration behavior. It can be extended withadditional information and constraints. The domainmodel is the central communication tool whichconstantly nourished with further insights andrequirements. The domain model classes need very littleConsider a scenario, where a satellite domainExpert, talking to the developer or with developmentteam. How does that conversion look like? It could beout of the box and this creates serious problems to our51ISSN (Print): 2278-8948, Volume-1, Issue-3, 2012

International Journal of Advanced Electrical and Electronics Engineering, (IJAEEE)project. Domain Experts have their own jargon and thedevelopment team has its own. The daily discussionswith Domain Experts and the team are represented theterminology embedded into code. So effect of need totranslate what you are talking about into code appearsand also the misunderstandings while getting translation.This all could lead to not good results due to not havingthe common language.So there is a need for some common languageshows up. Eric Evans calls this language as UbiquitousLanguage[1]. Your language is your model; this meansthat both Domain Experts and Developers should talkthe same language which is build on the model. Andchanges to the Ubiquitous Language means changes tothe Model. If Experts start using new terms this shouldbe represented in our model, in our code, diagrams andspeech.Satellite CommunicationThe satellite communications has demonstrated thatsatellite systems can satisfy many requirements. Theyare reliable, survivable, secure, and a cost effectivemethod of telecommunications. We can easily see thatsatellites are the ideal, if not often the only, solution toproblems of communicating with highly mobile forces.Satellites, if properly used, provide much neededoptions to large, fixed-ground installations.Communications via satellite is a natural outgrowthof modern technology and of the continuing demand forgreater capacity and higher quality in communications.The below figure represent the Satellite Domain Treeview structure having each aggregate with its boundaries(jus overview):Domain-Specific LanguageDomain-specific language is formal language usedto describe the business and professional tasks and fieldsof responsibility within the domain. Independent of theprogramming language, its purpose is to express clientrequirements and the software functions that aredesigned to meet them in the user's own terminology.This enables a more intensive and efficient exchangebetween domain experts, users and developers.The most important advantages of domain-drivendesign are the demand-oriented presentation of businessand professional logic (Domain model) within a userorientedCommon Language (domain-specific language)[6]. These result in faster analysis, design anddevelopment processes and, above all, in softwaresolutions that are entirely appropriate to customerrequirements. Such solutions give an adequaterepresentation of the client's needs in details.Case study - 01:Satellite Domain Knowledge RepresentationWhen it comes to the Satellite Domain, this domainknowledge represents very high level complexity forend users. The people who are from telecommunicationback ground can capture the terms easily and understandthe Domain flow; if the developer is from the computerscience background then it will be difficult whiledesigning the Domain Model. The fundamentalcomponents shown in below figure, the design of theoverall system determines the complexity of the variouscomponents and the manner in which the systemoperates. The basic design of a satellite Domain systemdepends to a great degree upon the characteristics of theorbit of the satellite and its behavior.DocumentationDocumentation is a continuous effort. We have todocument the model using free-text notes as we designit, we document the code as your write it.Documentation – in the sense of Eric Evans always usesthe ubiquitous language. Further documentationdescribes the APIs including the services that areexposing your domain model towards a client.CodeThe behavior of objects can be best expressed withcode. We basically do not put any code in the model, butwe nourish the generated code with additionalfunctionality. The initial result from a generator run onthe constructed model can therefore only represent thepreliminary object model. The specific behavior has tobe added manually by the software developers.Modeling is an Art - UML ModelFrom the inputs and outputs of the Business ProcessModel and the details of the use cases, begin toconstruct a domain model (high level business objects),sequence diagrams, collaboration diagrams and userinterface models [2]. These describe the 'things' in thenew system, the way those things interact and the52ISSN (Print): 2278-8948, Volume-1, Issue-3, 2012

International Journal of Advanced Electrical and Electronics Engineering, (IJAEEE)interface a user will use to execute use case scenarios.From the domain model, the user interface model andthe scenario diagrams create the Class Model. This is aprecise specification of the objects in the system, theirdata or attributes and their behaviour or operations.Domain objects may be abstracted into class hierarchiesusing inheritance.explicitly separate Domain Level [7], which livesbetween our Infrastructure and Application layers, likeon the below figure. Note, that isolating of your DomainLevel is very important.Agile ModelAgile software development permits the writing,embedding and testing of new or modified functionalrequirements at any time, even during the final phases ofa project. Nowadays Agile is a way to develop softwareand DDD is very comfortable with it and withtechniques of the Agile like TDD.Agile software development teams embrace change,accepting the idea that requirements will evolvethroughout a project [4]. The Agile specialistunderstand that because requirements evolve over timethat any early investment in detailed documentation willonly be wasted. Instead they will do just enough initialmodeling to identify their project scope and develop ahigh-level schedule and estimate; that’s all you reallyneed early in a project, so that’s all we should do.Scrum ModelScrum suggests that you freeze the requirements forthe current iteration to provide a level of stability for thedevelopers. If you do this then any change to arequirement you’re currently implementing should betreated as just another new requirement.Domain ModelThe domain model is an aggregation of everythingexpressing it [3]. That means it is the holisticcomposition of the technical domain model (includingthe constraints), code and documentation. Compared toa classic domain driven design approach nothing haschanged in this respect. Only – and this is the addedvalue – the model and the language to describe themodel are made much more explicit! They evolve aspart of the whole and are always up to date.III. EXPERIMENTSImplementation of Satellite Domain Model with LayeredArchitecture:Let us discuss the real time satellite domainimplementation in brief, the below architecture is oncomplete flow of the application with domain objects.This flow is based on the segregation of each layer withthe components and technologies - LayeredArchitecture. For the DDD it is very important since weUser Interface (Presentation Layer)Responsible for presenting information to the userand interpreting user commands. The User Interfaceclient is an Eclipse RCP based application composed ofthe GUI component and GUI Service component:GUI Service LayerThis is a thin layer which coordinates theapplication activity. It does not contain business logic. Itdoes not hold the state of the business objects, but it canhold the state of an application task progress. The GUIService component layer between the UI and othersubsystems, implements the patterns to load data fromthe server as required, populate and maintain theDomain Session and hides all concerns related to53ISSN (Print): 2278-8948, Volume-1, Issue-3, 2012

International Journal of Advanced Electrical and Electronics Engineering, (IJAEEE)GMF – ResultEMF: Ecore ComponentsThe Ecore components are related according to thishierarchy [9]:This will create the Java implementation of the EMFmodel in the current project, the generated code willconsists of the following:• model -- Interfaces and the Factory to create theJava classes• model.impl -- Concrete implementation of theinterfaces defined in model• model.util -- The Adapter FactoryThe central factory has methods for creating alldefined objects via createObjectName() methods, foreach attribute the generated interface and itsimplementation contains getter and (if allowed in themodel definition) setter methods. Each setter has also agenerated notification to observers of the model.Each generated interface extends the EObjectinterface. EObject is the base of every EMF class and isthe EMF equivalent of java.lang.Object. EObject and itscorresponding implementation classEObjectImplprovide a lightweight base class that lets the generatedinterfaces and classes participate in the EMF notificationand persistence frameworks. Every generated method istagged with @generated. If you want to manually adjustthe method you want to prevent that EMF overwrites themethod during the next generation run you have toremove this tag.Sequence DiagramThe data managed via different wire has beencaptured in the below predicted sequence diagram, hereeach layer plays vital role in order to perform effectiveperformance and to avoid excess amount of making callto Business layer.Generating Java code using the ecore and genmodelfiles in EMF:First and foremost we have to create two modelfiles, the .ecore and the .genmodel model. Based onthese two model files we can generate Java code byright-click on the root node of the .genmodel file asshown in the below figure and select Generate ModelCode.Here the GUI client maintains a separate DomainSession per scenario - i.e. if a user is making changes totwo scenarios, the changes for each scenario will be in55ISSN (Print): 2278-8948, Volume-1, Issue-3, 2012

International Journal of Advanced Electrical and Electronics Engineering, (IJAEEE)their own Domain Session and can be committed (ordiscarded) separately.Domain Services are tightly coupled to DomainSession and are provided to query the data in the domainsession, to navigate between domain aggregates in thedomain session and to modify the data.Domain Services also provide domain logic that istightly coupled with the Domain Model component butcannot easily be implemented directly in the domainobjects themselves, such as calculations involvingmultiple aggregates.Domain Services are used client side (though thereis no inherent restriction to prevent them being usedserver side).V. ACKNOWLEDGMENTSI am very grateful to my institution for theirconstant support. I sincerely thank Dr. N.N.S.S.R.KPrasad for his valuable guidance, suggestions, usefulremarks, and productive discussion which helped me toimprove the content and presentation of this paper.VI. CONCLUSIONThis paper has discussed the current trends andpractical usage of domain model in softwaredevelopment, in particular the definition and use ofdomain-specific languages, and their advantages anddisadvantages. It has been able to capture the futurerequirements and enhancements on domain specificlanguages. We have seen, how, where and when tointegrate the model technologies which has beencaptured and presented with simplified manner bydifferentiating each layer. We strongly believe that theindustry will increasingly adopt model drivenarchitecture and technologies with adopting themodeling technologies and tools. It represents that UMLas an important language act as a backbone for modeldriven architecture using agile process, because it act asa service bus between the developers, analyst anddomain experts. Today we are able to solve manycomplex applications, projects in customer language,making them to understand in their own language it isthrough our Modern Driven and Domain specific tools.We still need to focus more on this area in order to makemore enlightening to reach to developer, analyst anddomain experts to make extensive use of MDA andDMS.VII. REFERENCES[1] [Evans2003]"Domain-Driven Design: Tackling Complexity inSoftware",[2] [OMG-MDA]“MDA”, http://www.omg.org/mda/[3] [Greg Young -NDC2010]http://domaindrivendesign.org/library/young_2010[4] [Agile Requirement]http://www.agilemodeling.com/essays/agileRequirements.htm[5] [EMF-Eclipse]http://www.eclipse.org/modeling/emf/[6] [DDD-In-practicehttp://www.infoq.com/articles/ddd-in-practice[7] [DDD - Architecture]http://www.infoq.com/articles/ddd-evolvingarchitecture[8] Addison-Wesley 2003[9] http://download.eclipse.org/modeling/emf/emf/javadoc/2.8.0/org/eclipse/emf/ecore/packagesummary.html#details[10] http://www2.informatik.huberlin.de/~hs/Aktivitaeten/2011_Vino/Talks/Afternoon/08_Phil_Slides.pdf[11] http://www.vogella.com/articles/EclipseEMF/article.html[12] http://help.eclipse.org/juno/index.jsp56ISSN (Print): 2278-8948, Volume-1, Issue-3, 2012