decomposed, working software. Professional experience: 20+ years, mainly building products, in domains such as Patient logistics, Real estate, Manufacturing, Construction, Transportation, Oil & gas Community experience: DDDBE member - Occasional speaker, blogger and discusser of (D)DDD, CQRS & ES and Messaging and author of AggregateSource and Projac
expertise No (or too little) communication/collaboration No time to learn the problem/solution space No (or too little) design up front ( coz Agile ;-) ) No documentation/visualization
7: 8: 9: 10: 11: 12: 13: 14: 15: Guid Id { get; set; } string Name { get; set; } string Objective { get; set; } GroupType Type { get; set; } public public public public //... } //Usage var @group = new Group { Id = message.GroupId, Name = message.Name, Objective = message.Objective, Type = GroupType.Private };
for behaviour, such as validation, security, arithmetic, composition, ... They are the primitives of your model. They keep the repetition out of the wrong places and stimulate the use of acceptable values. They promote domain specific language in both their name and behaviors. They compose well and move us away from the procedural landscape. Still, don't go overboard (e.g. message obsession).
to find the right level of abstraction. For scenario driven tests that means being able to change your implementation without having to touch your tests. Try to assert that only what you expected occurred AND NOTHING ELSE. Keep the boilerplate/distraction out of your tests.