(Start any project with event storming. If you don’t know what is event storming, look at the later part of the blog, or there are tons of material out there in internet)
Talk to domain expert and understand the domain well. Translate that into the code. The domain code should reflect the real world domain. Functions, classes, objects, properties should have same names that are used in the real world, by the domain experts.
In business, when a same name is used in different places to denote different things, (ex: accounts in banking, policy in insurance, warrant/case in criminal justice) please follow the below points
The different places in which the same name are used might be a different context. Which had to separated as separate module/package/namespace/service.
Make it a point to discuss this with the domain expert and only after agreement, introduce specific names (which had to be adopted in the real world too)
Don’t shy away from picking up those discussions. (Else you are not doing DDD)
An aggregate (loosely treat this as module/package/namespace/service) is a one or more entities, (entities are things/people/actions uniquely identified by id), along with value objects. Entities belongs to this aggregate while value objects belong to different aggregate or context. We cannot/should not modify Value Objects. An aggregate should contain entities that are to be in sync for them to be valid business wise. Ex: in a tablet strip while last tablet is taken out, the tablet strip should be treated as an empty strip. While that said, try keeping an aggregate small. Before moving an entity into a different aggregate validate with business, if it is okey to daly (and also the duration of the delay) before the system becomes valid business wise. Ex: is it okay to place an order for a new strip of tablet with in another hour when a tablet strip gets empty.
Use domain events as message to be broadcasted to the other aggregates for them to act upon. Ex: “Tablet strip is emptied”, “Tablet had expired”.
Event Storming is a beautiful way to get started with this. Bring the whole team both dev and domain experts to gather into a room. Give the domain experts orange stickies and ask them to write down the events that happen in their business. One event per sticky. Events to be ordered in in time series in which they happen. The dev team should ask question on things that they don’t understand.
If you are lazy to pick a book and ready, I would highly recommend, workshops, enjoyable way to understand DDD.
Sandeep Jagtap's
https://learning.oreilly.com/live-events/domain-driven-design-boot-camp/0636920072004
Andrew Harmel-Law's
https://learning.oreilly.com/live-events/domain-driven-design-first-steps/0636920436867
This one will also highly recommended, for you understand the tech terms of DDD, though he may sound dry, he had covered breadth and some depth well.
Vaughn Vernon's
https://learning.oreilly.com/videos/domain-driven-design-distilled/9780134593449/
The last one, this to sounded simple.
https://www.youtube.com/playlist?list=PLzYkqgWkHPKDpXETRRsFv2F9ht6XdAF3v
