New answers tagged domain-driven-design
0
Where should you put behavior?
Your first choice should usually be in a value object, an entity or aggregate root (AR).
It’s the client that calls behavior on the AR. A client can call the repository twice with different id’s, to get two instances (x and y) of the AR. The client can then call the behavior on X and pass Y -> x.MoveAfter(y).
The ...
0
It really depends on what the information is for, if the intermediate state changes need to be preserved. For example, the analytics team might care in which order items were added to the cart, at what time (and which parts of the web site were visited leading to additional purchases). They probably want to send a reminder to the user if the check-out was ...
1
I think the answer to your question comes from defining what the failure states for your application are. Event based systems come in a couple flavors: persistent queues and objects passed in memory. Both of those have different types of failure states. For example, persistent queues write the event to disk until a client confirms receipt. Objects passed ...
8
In general DI should be supported in libraries. The actual implementation or selection of a DI Container should not be done by a library, that should be left to the root application.
That way the root application can decide on
whether or not to use DI
what DI library to use
which other dependencies to load/pass on to the library
DI support can be ...
2
Api.EmployeeController.Update(Api.EmployeeUpdateDto) => Services.EmployeeService.Update(Service.EmployeeUpdateDto) => Data.EmployeeRepository.Update(Entities.Employee) => Data.EfDbContext.Employees.Update(Entities.Employee
Let's look at it this way: what if you were to tell your business counterpart this? Just the above word-for-word.
I would wager he/she ...
6
It is unfortunately a popular form of DDD. I say unfortunately because it completely ignores the core principles of DDD, that is the actual modeling of the problem.
Having pure data structures does nothing to tell the reader what is happening, what problems are being solved, it does not use the Ubiquitous Language, since getting/setting stuff is rarely if ...
3
I see this as strict separation between the domain model and the persistence model. By duplicating this model, it becomes possible to fine-tune models for their specific purpose. One represents business rules, other is easy to persist and query. If it was just single model, it would be necessary to make tradeoff-s between the two.
This is specific way to ...
1
Greg Young's Polyglot Data talk includes a discussion of pull vs push.
Pub/sub is "fine" when you are dealing with a single message in isolation. It's also a reasonable choice when you need to handle sparse events with low latency.
But pull based solutions are a lot easier to reason about when you are dealing with sequences of messages. The consumer ...
2
A value object is an object that has no identity but is fully defined by its value. A timestamp fully fits that description, and so does an integer and a string.
At the same time, a timestamp can also be a property of a larger object. It is not a matter of choosing between either a value object or an attribute, because it is very normal for value objects to ...
answered Jan 16 at 15:48
Bart van Ingen Schenau
55.2k10 gold badges89 silver badges143 bronze badges
0
Is a timestamp a value object or a property of one?
This is up to you. It can even be both. Value objects can be composed of other value objects.
To be clear though, giving a primitive an useful name does not make it a Value Object:
class ActiveState
int timestamp <== A property that is not a value object (not an object at all)
class ActiveState (...
6
A timestamp is a value object: it has no identity and is solely defined by its value components.
In your case you could use a built-in type or go for your own value-type (eg a C# struct).
A value object can be a property of a larger object. Especially if it’s a value-type (There could be some subtle differences if your language would not support value ...
0
As far as I know there are two things your should consider by choosing aggregates. The first is your invariants. For example you have 2 properties x and y and the sum of them must be always 6. Obviously you cannot change them independently, because you would end up in invalid states. After identifying your invariants you will know you consistency boundaries ...
2
The core argument for using repositories is to prevent leaking EF dependent code into your domain. That argument is not wrong, it just comes with a steep cost, i.e. a high-complexity uow/repo layer, which is now being regarded (by some, at least) as too high a price to pay for what it gives back.
By not using that uow/repo layer, you do actually let your ...
0
The use-case in a clean architecture is as stable as the other inner circles and more stable than the outer circles such as presenters or UIs:
We do not expect changes in this layer to affect the entities. We also
do not expect this layer to be affected by changes to externalities
such as the database, the UI, or any of the common frameworks.
- ...
1
Having multiple value objects of the same type relate to an Entity is a common use-case.
What I usually do is to model my value objects differently, and try to understand if it's better to have a collection of value objects relate to the entity.
So in your case, your value object is actually an AddressCollection value object (in your code) and you can ...
2
An address object (which refers to a street address) can be modeled either as a value object or as an entity. The trade-off lies mostly in the database/storage layer.
If you design your storage to assign an ID to your address object, you are effectively choosing to treat your address objects as entities.
If you want to treat addresses as value objects, you ...
2
It seems to me like the fundamental problem you are getting at is the need to generate the Message objects as you call methods/fields on your Domain objects.
There's not much you can do about this if you want to do Event Sourcing. If you keep the simple ItemRepository, then when you call Save(Item) the underlying event source database has no way to work out ...
1
Since my initial post of this answer didn't accomplish what I wanted, I purchased the for-Kindle version of this book, and found exactly what I vaguely remembered, in order to directly answer the question
Why do we need so many classes in design patterns?
Short and sweet -- we don't. Exactly why that is true I'm not sure that I can put into words as ...
Top 50 recent answers are included
