DDD - Software design ( domain modelling)

Key things to keep in mind :

Inevitable - you do or not, good or bad, concisely or unconsciously
Adaptive not predictive - not perfect/ suitable for future, but more adaptive and malleable ( flexible, supple design)
Software Design is iterative
Design should be Evolving
Writing user story is a design decision/activity
Documenting tech/functional features is a design activity ( because its a design decision about interaction with systems, other integration features)
Most significant complexity of many applications is not technical, its domain itself, its in the user itself.
Product owner tells the business value of the software not how to design or architect it
DDD bridges the gap between non-tech and tech people

3 Domain types (domain distillation by Eric Evans )

Generic domain- what your business is doing , everyone else is also doing . Don’t write your own software, use libraries /off the shelf code with minimum to no coding/customisation
Supporting domain - specific to business ( some custom software development) - Write some software to support your core domain Use junior staff to code /outsourcer to develop this part
Core domain - smallest thing ( piece of software) that involves in excelling to immolate and differentiate with the market Explore, research, do in house with your best tech staff

Know your core domain
Focus on business goals
How the product will give a competitive edge over competition
Write as little custom software to deliver business goals ( re-use)
Purpose alignment model ( differentiator vs mission critical)
Create and enforce software boundaries -Every line of code that you write will have a lifetime and needs to be maintained, so define boundaries (Refer Playing filed matrix for the book “stand back and deliver”). Create boundaries using a context map ( Eric Evans book) :
Identifying boundaries
Creating boundaries
Enforcing domain boundaries for design
Integrate early ( integrate to isolate)

Learning to speak the language of business domain . Shared language between business and technical teams
Make teams understand what are “value objects”
Make teams understand what are aggregates
What are building block patters

TDD
Write a failing test
Make it pass
If not, Re-factor the code
Repeat the above 3 steps until the tests pas
Acquire limited liability int he code ( Eric Evans book reference)
Bake design into the process
Scrum is to structure things to accomplish some work on a regular basis
Design and development is the work ( design is more integral to development than Scrum)
Good design can accelerate product delivery in the mid to long term
Create design workshop with the business - to understand what the domain is trying to do ( which problems its trying to solve)
UX design is like iceberg of the application and software design the rest of it
Process should server the product development and not the other way round
Design for design book