Introduction to DDD
•Download as PPTX, PDF•
1 like•538 views
Domain driven design changed the way I did design. I wanted to introduce this to our new team. This presentation just introduces the main concepts of DDD. This is the first presentation that I am uploading to slides share.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
Similar to Introduction to DDD
Similar to Introduction to DDD (20)
Recently uploaded
Recently uploaded (20)
Introduction to DDD
- 1. Introduction to Domain Driven Design Ferose Khan J
- 2. 01 WHY BOTHER ABOUT DOMAIN?
- 3. Domain “Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the DOMAIN of the software.”
- 4. Story…
- 5. 02 IS UNDERSTANDING DOMAIN EASY?
- 6. Let’s have some fun
- 8. Crunching Knowledge • Brainstorming • Continuous learning • Effective modeling • Make concepts explicit
- 10. Communication • Ubiquitous language • Model out loud • One team one language • Documents & diagram aid communication
- 11. 03 HOW TO BIND MODEL & IMPLEMENTATION?
- 12. Problem Analysis Model Design model
- 13. Analysis model Module1 Module2 Module3 Module4 Module3 Module8 Module9 Module5 Module6
- 14. Design model
- 16. Ivory tower architect No feedback from team
- 17. Results in brave speeches in the end
- 18. Solutions is hands-on modelers
- 19. Do Model Driven Design • One model • Analysis and design one iterative loop • Design a little • Make code an expression of model
- 20. 04 WHAT ABOUT OTHER TECHNICAL REQUIREMENTS?
- 21. Isolate the domain from them
- 22. Model lives @Domain layer
- 23. 05 HOW TO EXPRESS MODEL IN S/W?
- 24. Entities
- 25. Value Objects
- 26. Associations
- 27. Services
- 28. 06 WHAT ABOUT THE LIFE CYCLE OF DOMAIN OBJECT?
- 29. Aggregates
- 30. Factories
- 31. Repositories
- 32. 07 SO WHAT?
- 33. Our Domain
- 34. Medical software • Saves life • Improves quality of life
- 35. Give a try
- 38. Ferose Khan Jeberla t @ferosekhanj d ferosekhanj.wordpress.com l http://lnkd.in/UJry2c
Editor's Notes
- What is a domain? With respect to software development. The user applies the program to solve some problem. The area where he applies is the domain.
- My sister bought a LG viewty long time back. It was a remarkable phone at that time. It had full touch screen, 5MP camera with digital image stabilization, excellent audio and music features, Built in office sw Etc., But she had one important problem. The number of calls dropped was pretty high. It did not fulfill its purpose as a phone. In the end she bought an additional phone a dumb one from nokia which did not have any of this fancy feature but it fulfilled the purpose as a phone. Similarly in software development also we have a core problem which we solve using the software. If the software is able to solve that problem well and good then it succeeds. If it performs all other functionalities excellently, but doesn't solve the core problem then it will fail.
- Select a participant. Provide the participant with a model. Now make 2 groups. Ask them to make the same model without disclosing them to the groups. The groups should reproduce the model just by questioning the participant.
- In order to come up with a solution first thing we need to know is understand the problem. Ask the domain expert regarding various clarification and distill the model. It is not a one time activity. Learning and revelations happen through out the life time of design. The models need to be deep not just a shallow one. Make sure you don’t just come up with a anemic data model. The model includes important aspects and leaves out the unimportant ones. Make the model knowledge rich. Only with careful discussion and distilling we can express the model properly in SW.
- Hands on modelers ivory tower architects Feedback from implementation missing Modeling & Implementation are part of modeling process Architects should do some hands on coding Designers should participate in model discussions
- Hands on modelers ivory tower architects Feedback from implementation missingModelling & Implementation are part of modelling process Architects should do some hands on coding\ Designers should participate in model discussions
- Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.Some objects are not defined primarily by their attributes. They represent a thread of identity that runs through time and often across distinct representations. Sometimes such an object must be matched with another object even though attributes differ. An object must be distinguished from other objects even though they might have the same attributes. Mistaken identity can lead to data corruption.When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model. Keep the class definition simple and focused on life cycle continuity and identity. Define a means of distinguishing each object regardless of its form or history. Be alert to requirements that call for matching objects by attributes. Define an operation that is guaranteed to produce a unique result for each object, possibly by attaching a symbol that is guaranteed unique. This means of identification may come from the outside, or it may be an arbitrary identifier created by and for the system, but it must correspond to the identity distinctions in the model. The model must define what it means to be the same thing.
- Many objects have no conceptual identity. These objects describe some characteristic of a thing.Tracking the identity of ENTITIES is essential, but attaching identity to other objects can hurt system performance, add analytical work, and muddle the model by making all objects look the same.Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary.However, if we think of this category of object as just the absence of identity, we haven't added much to our toolbox or vocabulary. In fact, these objects have characteristics of their own and their own significance to the model. These are the objects that describe things.When you care only about the attributes of an element of the model, classify it as a VALUE OBJECT. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the VALUE OBJECT as immutable. Don't give it any identity and avoid the design complexities necessary to maintain ENTITIES.
- There are at least three ways of making associations more tractable.Imposing a traversal directionAdding a qualifier, effectively reducing multiplicityEliminating nonessential associations
- The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT.The interface is defined in terms of other elements of the domain model.The operation is stateless.There are important domain operations that can't find a natural home in an ENTITY or VALUE OBJECT. Some of these are intrinsically activities or actions, not things, but since our modeling paradigm is objects, we try to fit them into objects anyway.Some concepts from the domain aren't natural to model as objects. Forcing the required domain functionality to be the responsibility of an ENTITY or VALUE either distorts the definition of a model-based object or adds meaningless artificial objects.
- It is difficult to guarantee the consistency of changes to objects in a model with complex associations. Invariants need to be maintained that apply to closely related groups of objects, not just discrete objects. Yet cautious locking schemes cause multiple users to interfere pointlessly with each other and make a system unusable.Cluster the ENTITIES and VALUE OBJECTS into AGGREGATES and define boundaries around each. Choose one ENTITY to be the root of each AGGREGATE, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to the root only. Transient references to internal members can be passed out for use within a single operation only. Because the root controls access, it cannot be blindsided by changes to the internals. This arrangement makes it practical to enforce all invariants for objects in the AGGREGATE and for the AGGREGATE as a whole in any state change.
- When creation of an object, or an entire AGGREGATE, becomes complicated or reveals too much of the internal structure, FACTORIES provide encapsulation.Creation of an object can be a major operation in itself, but complex assembly operations do not fit the responsibility of the created objects. Combining such responsibilities can produce ungainly designs that are hard to understand. Making the client direct construction muddies the design of the client, breaches encapsulation of the assembled object or AGGREGATE, and overly couples the client to the implementation of the created object.
- Associations allow us to find an object based on its relationship to another. But we must have a starting point for a traversal to an ENTITY or VALUE in the middle of its life cycle.A client needs a practical means of acquiring references to preexisting domain objects. If the infrastructure makes it easy to do so, the developers of the client may add more traversable associations, muddling the model. On the other hand, they may use queries to pull the exact data they need from the database, or to pull a few specific objects rather than navigating from AGGREGATE roots. Domain logic moves into queries and client code, and the ENTITIES and VALUE OBJECTS become mere data containers. The sheer technical complexity of applying most database access infrastructure quickly swamps the client code, which leads developers to dumb down the domain layer, which makes the model irrelevant.
- Introduction about the presenter.I am ferose. I work for Siemens from 2003. Formally I was with the Oncology software development team for about 10 years. I recently joined AX. My area of expertise includes software design, architecture & 2D/3D medical image processing. I am from TN and I have a small family.