Mais conteúdo relacionado

Apresentações para você(20)

Domain driven design and model driven development

  1. Domain Driven Design and Model Driven Development Geyzersky Dmitry IT Architect, Co-Owner of PerformIT
  2. “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.“ Martin Fowler
  3. Session Objectives and Agenda • Introduction to Ontology. • From the Ontology to Domain Driven Design. • DDD Building Blocks. • Modeling Techniques.
  4. Ontology • In philosophy ontology is the theory of the nature of existence. • In the context of information science it is the study of entities and their relations. • It is about modeling a domain of knowledge by using high level of abstraction.
  5. Ontology and Semantic Technologies
  6. Domain Driven Design • Model driven software design approach used to tackle complexity of software projects. • DDD focuses on the domain logic. • The term was coined by Eric Evans in his book.
  7. “Strategy is doing the right things, tactics is doing things right.“ Peter Ferdinand Drucker
  8. Ubiquitous Language • Learn and talk the language of the domain experts. • The language evolves with the domain model and enables to describe the characteristics of the domain with increased precision. • Change in the language = change in the model and vice versa. • Knowledge crunching.
  9. Creating Ubiquitous Language
  10. Domain Model • Model is the backbone of Domain Driven Design. • Model forms ubiquitous language. • Perfect tool for communication between domain experts and developers. • Explains complex domain in a simple way. • Model and Code are bound.
  11. Layering
  12. DDD Building Blocks Domain Model
  13. Entities Objects having a unique identity throughout the states of the software.
  14. Entities We compare entities by their IDs.
  15. Value Objects • Objects describing certain aspects of the domain which don’t have identity and lifecycle. • Immutable - if you need to change the object, just create a new one.
  16. Value Objects • We compare Value Types by comparing their properties one-by-one.
  17. Repositories • A Repository encapsulates domain objects persistence and retrieval. • Clean separation and one-way dependency between the domain and data mapping layers. • Usually implemented with Object Relational Mapping (ORM) techniques. • May encapsulate different fetching strategies, distributed caching, NoSQL and etc.
  18. Services • Define an application's boundary. • Services usually manipulate Entities and Value Objects. • A service typically implements a business rule, generally something that software must do.
  19. Aggregates • Each Aggregate has one Root Entity. • The root identity is global, the identities of entities inside are local. • External objects may have references only to root. • Internal objects cannot be changed outside the Aggregate.
  20. Factories • A program elements whose responsibility is the creation of other objects. • Create and manage complex domain objects. • Especially useful for creating aggregates when atomicity is required.
  21. Domain Events Represent the states of Entities
  22. DDD Challenges • The model must reflect code changes and vice versa. • The amount of boilerplate code must be as minimal as possible. • The main focus is on the business domain and not the infrastructure. • Minimum friction with technology. • Continuous integration, testing and refactory. • As much automation as possible.
  23. Code Generation Techniques • NHibernate with NVelocity (.Net). • Xtext with Xtend (Java, Eclipse). • Protege (Java). • Enterprise Architect (any language). • MS Entity Framework (.Net) with T4. • UML (any language). • Spring Data (Java, Neo4J) and etc.
  24. References • Domain-Driven Design: Tackling Complexity in the Heart of Software (by Eric Evans). • • • • A Legal Case OWL Ontology with an Instantiation of Popov v. Hayashi Adam Wyner and Rinke Hoekstra, Knowledge Engineering Review.
  25. For more information: or