How to Implement Domain Driven Design in Real Life SDLC
- 1. The way I learn DDD! - Abdul Karim Software Engineer Dhaka, Bangladesh
- 2. What we traditionally do when we start a business application development? • We develop a SRS • We read the SRS and find the functionalities. • We breakdown tasks. In most of the cases the goal of the breakdown is to come up with an estimation and plan of works. • We do the estimation. • We distribute the works among team members. • We go for a UI Mockup • We design the database schema - sometimes by the team leader or sometimes by the respective developer. • We start coding.
- 3. • So? What’s wrong with this approach? We have been doing good! Don’t we?
- 4. • The answer is YES and NO! • Yes we are doing good in delivering our projects to client. • But NO! We are not doing good in maintaining and extending our projects!
- 5. • Think about all of the projects you have worked last few years in the traditional approach. Did you ever face any of the issues below? 1. Your project has the same functionality implemented in the same way or different in different places. 2. You have more than one object for the same item. 3. You have objects that has properties that are not actually attributes of that object. 4. You have no or very poor relationship among related items. 5. Looking at your objects it is not possible to understand what actually the whole application is all about.
- 6. I am sure you have been facing these issues regularly though we have successfully finished our project. But do you know why?
- 7. The reason is, traditional approach do not guide us designing the system in Up to Bottom fashion. Rather it tempted us to design the system in Bottom-Up fashion. See, when you design a system you need to know what as a whole the application will do? What is the goal the client is trying to achieve. Then, from the top level goal you come up with different smaller functionalities that will eventually allow the users to achieve the top level goal. But when you design in bottom-up approach, you first design for the granular functionalities, and you have little or no knowledge how this functionality will be used from the Top level and how the Top level functionalities will actually look like.
- 8. • Have you ever heard that a developer of your team is talking like he does not have the domain knowledge of the whole application? Perhaps yes! • I think you can understand the reason. Cause, the design of the application does not represent the domain of the system. And so, developers know only the portions they worked. • Developer has to depend on the box he knows only. • This is Sad! Isn’t it?
- 9. • So, is traditional approach – “Designing the application starting from database” a throw away concept? • Not really! But if you have a complex application to develop, this bottom-up design approach do not dictate you to come up with a proper object oriented design. • What is the solution then?
- 10. One of the solution might be DDD DDD = DOMAIN DRIVEN DESIGN
- 11. DDD Module
- 12. What is DDD? Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains. - Wikipedia
- 13. Concepts to Cover in this Session: • Understanding the Domain • Ubiquitous Language • Core Domain • Model • Contexts and Bounded Contexts • Entities and Value Objects • Aggregates and Aggregate Roots • Persistence Ignorance • Repository • Domain Service • Specification
- 14. In this session I will try to avoid to become too technical, rather I will try to go through different concepts of DDD being close to the real world. I will not show any code here. Cause I believe if you understand the concept and starts thinking in DDD way, implementation is easy. The toughest part is to tune our thinking process!
- 15. Understanding the Domain • A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. -Wikipedia So, do you get a feeling what is domain? Can you tell what is the domain of the MyEdu project that we are working on? Can you tell what is the domain of the famous website YouTube?
- 16. • In this session I would like to go through a real world example to give you the feeling how to start analyzing your project driven by your domain. This example may not be related with application development but as the goal is to tune our thinking top to bottom manner, it will be useful. • But Yes! We will go through the technical terms of DDD too!
- 17. • Let’s say you are engaged to design a building. The requirement is: – You have a defined amount of land – Your building will have 6 floor. – Each floor will have 4 apartments. • You need to design the building. • So, What is our domain here? • The domain is Building? It could be. But note that, if we consider Building as our domain we may miss few granular detail for our requirement. The building we are going to design must have design for apartments where people will live. So, a general term “Building” can make us miss few detail. • So?
- 18. • So, we may narrow down our domain to “Residential Building”. • Now, when we talk about our work with engineers and also with the people who assigned us to design the term “Residential Building” is more meaningful for everybody concerned. • Did you mark very small change in language here? The contractor is telling you to design a building where there will be 4 apartments in each of the 6 floors. Now, if you send an engineer to the site telling him we will need to construct a building there, they might not consider many attributes that a residential building must have. On the other hand if you use the term “Residential Building”, most likely he will come with a valid analysis. • This is how we come to an “Ubiquitous Language”.
- 19. Ubiquitous Language • The concept is simple, that developers and the business should share a common language, that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology. More Example: • Wrong language: The length and width ratio of the smaller bed rooms would be 4:3. • Correct language: The children's bed room’s length will be 20 ft and width will be 15 ft. Note, that to the owner of the building smaller room, ratio all these things could be very technical terms. Rather it is easier for him to understand children's room, guest room, living room etc. And explicit measurement is more meaningful to him.
- 20. Ubiquitous Language More Example: Now, let’s talk about an example of a software perspective: Wrong language: In search functionality we will consider inflectional and thesaurus feature of sql server to make the search more relevant. Additionally we will also exclude the stop words from the search to make it more accurate. Note that, your domain expert may not be a technical person and thus he may not understand what you meant by the words “Inflectional”, “Thesaurus”, “Stop word” etc. Correct language: In the search functionality we will consider all the synonyms of the search phrase so that it does not exclude relevant results. Moreover we will not differentiate any search word by it’s number(singular or plural), tense, participle etc so that the result becomes more accurate. Additionally as expected in any search, we will ignore all the noise words that do not have any value in the search. Such noise words could be “am”, “but”, “where”, “about” etc.
- 21. Define Ubiquitous Language Ubiquitous language A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
- 22. • Let’s come back to our “Residential Building” domain. • Look, we can proceed with the residential building design as a single task and address the whole thing together. But will it really be very wise way to do? • Note that if we just consider this a single unit of work we may miss many things. Designing a building is related so many things. For example: We need to consider ventilation, utility, parking space, community space etc. • Now you see, different other contexts are coming up. • This is how the concept “Context” and “Bounded Context” comes up in Domain Driven Design.
- 23. Not all of a large and complex system will be well designed.
- 24. That is why first distilling the Core Domain
- 25. Distilling the Core Domain Generic Subdomains
- 26. Distilling the Core Domain Generic Subdomains Supporting Subdomains
- 27. Distilling the Core Domain Generic Subdomains Supporting Subdomains Core Domain
- 28. Distilling the Core Domain – What makes your system worth writing?
- 29. Distilling the Core Domain – What makes your system worth writing? – Why not buy it off the shelf?
- 30. Distilling the Core Domain – What makes your system worth writing? – Why not buy it off the shelf? – Why not outsource it?
- 31. Distilling the Core Domain – What makes your system worth writing? – Why not buy it off the shelf? – Why not outsource it?
- 36. Ground Up Rebuild Legacy Replaced Year 1 Exciting New Features Year 2 Year 3
- 37. Which Part is Core?
- 38. Which Part is Core?
- 39. Responsibility Traps …Or, Why do irresponsible programmers become heroes?
- 40. Responsibility Traps • Building a platform to make other (lesser) programmers more productive. • Cleaning up other people’s mess.
- 41. What’s a responsible designer to do?!!
- 42. How could we just build the core part?
- 43. Build Platform Based on Model
- 44. Build Platform Based on Model
- 45. Strategy • Draw a Context Map. • Work with business leadership to define Core Domain. • Design a platform that supports work in the Core Domain. • Work with management to give freedom to the Core Domain Platform Context. • Develop and model in the Core Domain.
- 46. Define Model model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
- 47. Define Model model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
- 48. Define Model model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
- 49. Contexts and Bounded Contexts A Bounded Context can be considered as a miniature application, containing it’s own Domain, own code and persistence mechanisms. Within a Bounded Context, there should be logical consistency, each Bounded Context should be independent of any other Bounded Context.
- 50. Contexts and Bounded Contexts More Example: Think of an e-Commerce system. Initially you can tell it is an application of shopping context. But if you look more closely, you will see there are other contexts too. Like: Inventory, Delivery, Accounts etc. Dividing a large application among different bounded contexts properly will allow us to make our application more modular, will help us to separate different concerns and will make the application easy to manage and enhance. Each of these Bounded Contexts has a specific responsibility, and can operate in a semiautonomous fashion. By splitting these apart it becomes more obvious where logic should sit, and we can avoid that BBOM (Big ball of mud)
- 51. • What is BBOM? A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and- baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. - Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997 Our all time objective should be to avoid BBOM
- 52. • Again with the “Residential Building Domain” • So, we could have several bounded contexts: – Electricity supply – Car parking – Apartment – Etc. • Let’s talk about the apartment. The apartment is basically a combination of different rooms. The rooms have different elements inside. like windows, doors etc. • Now I have 2 questions about the windows of the room.
- 53. • Question1: Can you imagine a window without a room? • Question2: Does a window have any identity without the room it is residing in? • Answering the question will expose the following concepts of DDD in-front of you: 1. Entity. 2. Value Object. 3. Aggregates & Aggregate root.
- 54. Entity “This is my Entity, there are many like it, but this one is mine” The key defining characteristic of an Entity is that it has an Identity – it is unique within the system, and no other Entity, no matter how similar is the same Entity unless it has the same Identity. Examples: 1. My bed room in the apartment 2. Contract in Facebook.
- 55. Value Object The key defining characteristic of a Value Objects is that it has no Identity. Ok, perhaps a little simplistic, but the intention of a Value Object is to represent something by it’s attributes only. Two VOs may have identical attributes, in which case they are identical. They don’t however have any value other than by virtue of their attributes. Another aspect common to VOs is that they should probably be immutable, once created they cannot be changed or altered. You can create a new one, and as they have no identity, that is just the same as changing another one. Example: 1. Windows in the rooms 2. Address of any person in Assess of MIST or other apps. 3. SearchCriteria in MIST Query Analyzer search engine. Note: A value object can become an entity depending on the situation. Can you find a scenario when SearchCriteria of MIST Query Analyzer can be an entity?
- 56. • So, now we know what is entity and what is value object in DDD. • In domain driven design entities and value objects can exist independently. But in some cases the relation can be such that, an entity or VO has no value without its context. • For example: 1. A window can only be defined if there is a room. 2. An order note can only exist if an order is placed. 3. A question detail can only be there if a question is asked. Very simple isn’t it? Believe me, now you know what is Aggregates and what is Aggregate root.
- 57. • we have already discussed the concept of aggregate and aggregate root. • In the examples we have given: – Room, Order and Question are our aggregate roots. – On the other hand window, order note and question detail are our aggregates.
- 58. Aggregate and Aggregate Root “A cluster of associated objects that are treated as a unit with regard to data changes.” All objects of the clusters should be treated as aggregate. All external access to the cluster is through a single root Entity. This root entity is defined as aggregate root.
- 59. • Example: • A question detail should no way be saved unless the corresponding question is saved. • A question detail should no way be retrieved unless the corosponding question is retrieved. • Here Question is the Aggregate root and Question Detail is the aggregate. Aggregates and Aggregates Root are very important concept of DDD. Do you have any questions on this?
- 60. Persistence Ignorance So far we have talked about domain, objects/entities, contexts, aggregates etc. What about the Database? Is that something we have missed? Isn’t it something should come in the design? • The answer is NO! DDD is a persistence ignorant approach.
- 61. Persistence Ignorance • In domain driven design your objective is to create a model of the domain. You need to identify what are the items (objects) you need to have to accomplish the desired functionalities of your application domain. You need to identify the relationships among different objects and how they interact among themselves. You need to find if the business goal of your client is achievable using your domain model. • Where is the existence of database here? You do not need to know how and where the data of your domain will persist or even if the data do need to persist while you do the model of the domain.
- 62. Persistence Ignorance • This ignorance about your persistence medium will make your domain model free from any coupling with the persistence layer of the application. This will eventually separate the concerns of the persistence and its communication mechanism from your domain model. In result your application will be free from coupling with any data store and will be very easily unit testable. • But Yes! In a real application you do need to have a database. But your domain model will have no knowledge about that. All it will know is the “Repository” which will eventually manage your application’s persistence concern. • It will be more clear as I will go little more detail about repository.
- 63. Repository • Tell me what is the meaning of the English word “Repository”? Repository commonly refers to a location for storage, often for safety or preservation. -Wikipedia As we already told that your domain model will not know any database. What it will know is, there is a repository in the system and that repository will be responsible to store your data and to retrieve your data. It is now way a concern of your domain model how and where data will persist. So, it can be Sql server, oracle, xml, text file or anything else. I hope now you got a sense what a repository means in DDD.
- 64. Repository • Let’s become little more technical. Repository Mediates between the domain and data mapping using a collection-like interface for accessing domain objects. It is more like a facade to your data store that pretend like a collection of your domain. Repository Is Not A Data Access Layer Note that repository doesn’t talk in terms of “data”, it talks in terms of Aggregate Roots. You can tell your Repository to add an Aggregate Root into it’s collection, or you can ask it for a particular Aggregate Root. When you remember that Aggregate Roots may comprise one or many Entities and Value Objects, this makes it fairly different to a traditional DAL that returns you back a set of rows from your database tables.
- 65. Repository • Implementation strategy: 1. 1st of all you will have an interface - IRepository that should be generic. 2. You will have an abstract implementation of the IRepository interface 3. You will have interface for your persistence mechanism like for Nhibernate - INhRepository this will inherit from IReposiroty 4. You will have implementation of INhReposiroty in a class like “NhReposirory”. 5. Finally you may have a generic implementation of the repository that will have default implementations of all the common methods of the repository. 6. Like NHGenericRepository that inherits from NhRepository and implments IGenericNhReposirtory. 7. Your application will use service locator to find which repository the application will use. I know the above implementation strategy may not be clear to all of you. But to explain the repository implementation in more detail with example is out of the scope of this presentation. We may need separate session on this. If you review the code of IWM Entityframework GenericRepository you will find a super implementation of this concept.
- 66. Domain Service • Domain service is another important concept of DDD. if Entities and Value Objects are the “things” in our Domain, the Services are a way of dealing with actions, operations and activities. Shouldn’t Logic Be on the Entities Directly? Yes, it really should. We should be modeling our Entities with the logic that relates to them and their children. But, there are occasions when we need to deal with complex operations or external responsibilities or may be we need to expose the actions of the aggregate roots to the external world. This is why creating a domain service for different aggregate root is a good idea. You can consider the domain services as façade layer of the business logics and operations of your domain.
- 67. Specification • A design pattern • A Specification is, in simple terms, a small piece of logic that sits on it’s own and gives an answer to a simple question … “does this match?” • Example: • We have a Customer, and we want to be able check if they are eligible for a discount on a Product. If we were to put a method on the Customer entity, for example .IsEntitledToDiscountPrice(Product) we start to couple our entities tightly together, and as the number of questions we want to ask of our entity increases, the more polluted its interface becomes. The Solution here is Specification.
- 68. Specification Code copied from: Domain_Driven_Design_-_Step_by_Step by Casey Charlton
- 69. Important Links • http://www.dddcommunity.org/ • http://thinkddd.com/ • http://www.infoq.com/minibooks/domain-driven-design-quickly • http://thinkddd.com/assets/2/Domain_Driven_Design_-_Step_by_Step.pdf • http://www.dddcommunity.org/library/young_2010 • http://www.dddcommunity.org/library/evans_2010 • http://blog.fossmo.net/post/Command-and-Query-Responsibility-Segregation-(CQRS).aspx • http://msdn.microsoft.com/en-us/library/ff649690.aspx
- 70. • I just try to learn DDD by myself. • Some slides are collected from internet [email protected]