1. PhD
2. Domain Driven Design
2.1. What is Domain Driven Design?
2.1.1. Way of looking at software from top-down.
2.1.2. Focus should be on business or activitiy rather than technology
2.1.3. Develop models of that domain and make our software conformed to that
2.2. What does DDD gives us?
2.2.1. Strategic Design Tools
2.2.1.1. Domain (Farm House)
2.2.1.1.1. Consist of
2.2.1.1.2. What is Domain Model?
2.2.1.2. What is Strategic Design?
2.2.1.2.1. **Object Oriented Design**: Think in terms of Objects
2.2.1.2.2. **Strategic Design**: Think in terms of Contexts
2.2.1.2.3. What is Context?
2.2.1.3. What are Strategic Design Tools?
2.2.1.3.1. Tools
2.2.1.3.2. Example
2.2.2. Tactical Design Tools
2.2.2.1. Mainly consist of
2.2.2.1.1. Service
2.2.2.2. What are Tactical Design Tools?
2.2.2.2.1. Tatical design tools are concerned with implementation details
2.2.2.2.2. Generally takes care of components inside a bounded context
2.2.2.2.3. A de facto standard in developement world
2.2.2.2.4. Things like services, entities, repositories, factories made popular by DDD
2.2.2.2.5. Contrary to strategic design, tactical design is expected to change during product development
2.2.2.3. Which are Tactical Design Tools?
2.2.2.3.1. Model Driven Design
2.2.2.3.2. Layered Architecture
2.2.2.3.3. Value Objects
2.2.2.3.4. Entities
2.2.2.3.5. Aggregates
2.2.2.3.6. Factories and Repositories
2.3. Why should I learn DDD?
2.3.1. To improve your craft
2.3.2. It's not customer's job to know what they want
2.3.3. End users decides wheather your system is fabulas or not
2.3.4. A system that doesnt solve the business needs is of no use to anyone
2.3.5. Example: - Windows 8 was well architect than Windows 7 - But it was giving features that were not needed to end users
2.4. 2 Spaces
2.4.1. Problem Space
2.4.1.1. Domain
2.4.1.1.1. Consist of
2.4.2. Solution Space
2.4.2.1. Domain Model
2.4.2.1.1. Bounded Context
2.4.2.1.2. Context Map
2.4.2.1.3. Ubiquitos Language
2.5. What did we learn?
2.5.1. Designing a city analogy
2.5.1.1. Unplanned
2.5.1.2. Planned
2.5.2. Key points
2.5.2.1. Always design your software in Top-Down fashion, unless your domain is trivial
2.5.2.2. Focus on what distinguishes you from competitors and understand what you must excel at
2.5.2.3. Always focus all your energy and resouces in your core sub-domain
2.5.2.4. Dont chase shiny objects by throwing technology at business problems
2.5.2.5. Place emphasis on naming and operations
2.5.3. Important tips
2.5.3.1. Don't work for a company that thinks of software as a cost centre
2.5.3.2. DDD will look just like OOP when you get the hang of it
2.5.3.3. Don't create heavy weight blueprints before development, follow an evolutionary approach
2.5.3.4. Write your code and documentation so that it represents the domain
2.5.3.5. Build a product for which you can provide long term warranties
3. Implementing Domain Driven Design
3.1. Its a book
3.1.1. A popular book by Vaugh Vernon
3.1.2. Relatively new, published in 2013
3.1.3. Next version published in 2016 known as "DDD Distilled"
3.1.4. Doesn't add anything new, but adds good examples on how to implement DDD
3.2. How would you discuss your understadning with domain expert? (old ways)
3.2.1. Use Case Diagram?
3.2.2. Activity Diagram?
3.2.3. Sequence Diagram?
3.2.4. ER Diagram?
3.3. What else we have now? (new way)
3.3.1. Event storming
3.3.1.1. What is Event storming
3.3.1.1.1. An exercise for creating Domain Models for strategic design
3.3.1.1.2. Becoming very popular in recent times
3.3.1.1.3. In simple words it is a brain storming workshop among domain experts and technology poeple to understand the events in a system
3.3.1.1.4. It is aimed to achieve a common understanding of the domain in which software must operate
3.3.1.2. How does event storming work?
3.3.1.2.1. First bring the right people in
3.3.1.2.2. Then take sticky notes and colour node them to events, commands, policies, processes, errors, roles and aggregates etc.
3.3.1.2.3. Take a white board and start writing interesting events in sequence ( eg. Items Browsed -> Item purchased -> Item shipped -> Item delivered )
3.3.1.2.4. Then start adding commands, aggregates, policies etc
3.3.1.2.5. After the first pass, start identifying bounded contexts (eg. Catalog, Payments, Delivery)
3.3.2. DDD in code
3.3.2.1. What is DDD in code?
3.3.2.1.1. Traid Fair Analogy
3.3.2.1.2. Value Objects aka Domain Primitives
4. Monoliths
4.1. Problem Statement
4.1.1. Develop a server-side enterprise application
4.1.2. It must support a variety of different clients including dekstop browsers, mobile browsers and native mobile applications
4.1.3. It might also integrate with other applications via either web services or a message broker like payment gateways and notification services
4.1.4. The application handles requests (HTTP requests and messages) by executing business logic, acessing a database, exchangin messages with other systems, and returning a JSON response
4.2. Traditional Server-Side App
4.2.1. Controllers
4.2.2. Services
4.2.3. DAOs
4.3. Advantages
4.3.1. Simple to develop
4.3.2. Simple to depoy
4.3.3. Simple to manage
4.3.4. Easy to understand
4.3.5. Simple to test
4.3.6. Easy to scale upto some level
4.4. Disadvantages
4.4.1. Language/Framework lock
4.4.2. Difficult to digest
4.4.3. Difficult to distribute development
4.4.4. Deployment as a single unit
4.4.5. Deplopment slows down
4.4.6. Resources are not optimized
4.4.7. Scaling becomes difficult