New answers tagged domain-driven-design
4
IMO this is a false dichotomy. If you follow SRP, you keep your system simple overall. Multiple small classes tend to be more "simple" (in many cases) rather than fewer large classes. Plus it seems like you are conflating two issues: how you design your classes vs. how you design your database. The two do not need to be related.
In your given case, it ...
3
You're confusing KISS; simple isn't referring to simple to implement for the developer, it refers to simple design, simple to understand and use. Following SRP makes your code simpler to understand and use because it's simpler to use a purpose built class for a single purpose than a multipurpose class, it's also simpler to maintain.
SRP supports Simplicity, ...
1
Once an entity is assigned a unique ID, its identity is established
and so I would assume such an entity doesn't need any behavior to
maintain its identity or to help it identify itself. Thus, I don't
understand what kind of behavior is author referring to ( besides find
and match operations ) with "behavior that is essential to the
concept"?
...
1
Very good question. The SRP shouldn't be taken quite so literrally. Identification/lookup isn't the responsibility of the entity in the regards to the SRP. Someone else is responsible for giving it an ID (namely the store) and for looking it up (namely the Repository).
The primary purpose of an entity is to represent the concepts uncovered by the model. The ...
2
Behavior in this context is refering to semantic behavior. For example, a Property on a class (i.e. attribute on a domain object) that is used to uniquely identify it has a behavior. While this is not represented in code directly. The expected behavior is that there will not be any duplicate values for that property. Something such as an Address which may ...
0
What would you do if the message was in a database? Do the exact same thing. A web service is just another storage device, in essence.
Your calling code should know nothing of the repository implementation details, if at all possible. Database, text file, web service, it's all GetMessage().
2
Just abstract the web service into a domain service and encapsulate it inside an implementation. That is why services in DDD exist. To abstract and encapsulate the outside world.
4
The distinction between Entity and Value object should be based around the question: If I have two objects with the same contents (two AdvertisementEvents linking to the same Banner with the same parameters), should I treat them differently or can one be replaced by the other without affecting how the software works?
In this case, I would say that you can ...
3
Sure, go ahead. Write your constructor so that it requires all fields that are required in the usual, "happy-path" rout to creating a customer. If it works, great! You've completed part of the requirements and enforced the integrity of a key data asset at the same time.
If it doesn't work, you will have learnt something about the system that you didn't ...
Top 50 recent answers are included
