Domain Driven Architecture for Domain Experts Knowledge - IRD India

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