New answers tagged domain-driven-design
1
A user-defined type that gets used as a parameter in an interface and that is only meaningful in conjunction with that interface (like your Aparams) should be declared in the same file/module as the interface.
That ensures on the one hand that there is only one definition of the type, regardless of how many implementations of the interface you get and on the ...
2
In Vertical Slice Architecture (VSA) you are supposed to have a class for pretty much every operation you can do (as I understand it)
Not literally every operation. Every cohesive group of operations. (And the article talks about slices, like "vertical layers", not just classes - a slice will often contain of more than just one class).
A good ...
1
The most common answer is to treat your reference data like any other input data - if you need that data to correctly interpret the history, then you copy that reference data into this history.
What you can sometimes do is copy into your history a key that can be used to look up an immutable copy of the reference data. (Think "commit id" from git =...
3
Is it really the intention, to make so many similar services/handlers/whatever-we-call-them?
As far as I can tell, you only create so many similar services/whatever if you have so many similar user-facing features or API endpoints.
Thus, if changing both a Customer's phone number and address requires me to fill and submit 2 forms, then VSA recommends to ...
3
Adding two responsibilities to the addClaps methods is a violation of the single responsibility principle.
I think going with domain events is a good way. It would allow you to centralize all the logic giving karma. It is not hard to imagine that a user could get karma in different ways than receiving claps. For example, being posting sketches or being an ...
0
There are no issues in having a many-to-many relationship between Theads an Participants. The decision is not about the relationship but instead about the consistency that you want to enforce.
Should you be able to retrieve all threads and look at their participants?
Should you be able to retrieve all participants and look all their thread?
given a ...
0
DDD is about how you model the domain knowledge. DDD could care if a user speaks some language but hasn't anything to do with the way the message is represented. This is an application concern, so it is definetly an application logic resposibility, thus only controllers/middlewares could know about the need to translate. Domain classes could store and ...
0
If you look at it from the perspective of object-orientation, there is really no visible difference at all. Both CA and DDD are procedural approaches, and try to improve on the usual procedural architectures and designs (like the Layered Architecture, etc.) by introducing some constraints that are technical in nature and somewhat arbitrary.
They differ on ...
0
I have a hard time understanding most of your question so I’ll focus on the last two sentences: ‘What is the DDD way of handling localization? Am I missing any options?’
The goal of DDD is to tackle complex business logic. This is best done when the user issues commands. For example:
a user enters some data in a form and presses a button
the system loads ...
1
There are different understandings of the presentation layer.
The traditional layered architecture that you describe predates the internet and in fact originates from the three tier architecture model. In this view:
the presentation layer corresponds to the client component that offers the user interface and communicates with a backend which runs on an ...
1
A presentation layer is a presentation layer regardless of how the rest of your app is built.
You mention single page web apps (spa), rest, angular, spring, n-tier, etc. but a presentation layers job is still the same: combine data with a way to consume it.
That might be visual, auditory, or even tactile. It might be a GUI, a console, printed paper, plotter, ...
0
Direct feedback
If the join table has state and behaviour then use a join class.
Yes, but if the join table has additional state (i.e. not just the FKs) of its own, that generally means that the domain to some degree recognizes this join class as an entity. It makes no sense to track state for something which you don't acknowledge exists.
Barring auxiliary ...
-1
I do agree with @VincentSavard that although it is true that the Change Tracking is an implementation detail with regarding to DDD. It is still a detail that needs to be tackled. And it is very true that there simply aren't articles/code samples that illustrate this (or I just haven't found them).
Anyway I have written a sample application which uses DDD ...
1
I would model the TaskList similar to the second approach because it better reflects the domain model from the business perspective. You have a tasklist with a bunch of tasks in it. Having the task know to which tasklist it belongs better fits to the data model (e.g. in a relational database).
But I would suggest some minor change that from my experience ...
2
So is there anything wrong with this approach that I'm not thinking of?
The usual design is to keep the domain model decoupled from the source of the information that it consumes.
In an idealized form, what this would normally look like is that your application code is coupled to "the plumbing" that knows how to obtain a copy of the data, the ...
1
Theoretically, whether the data comes from a database or other SOAP/external service doesn't matter, right?
When you consider the data handling algorithm, the method of fetching the data doesn't matter. But that doesn't lead to the conclusion that domain services are part of the domain.
Quite the opposite, in fact. It suggests that the domain shouldn't ...
0
Your approach, fetching the data in the repository that also gets data from the db, will work, but it does indeed create some coupling. There's also no nice seperation of concerns and the repository will no longer have a single reason to change.
Another approach could be to create an interface in your domain layer and inject the implementation into the ...
1
What is the kind of this dependency on the external service?
If we are talking DDD, I'd imagine that it works on the write side. I.e. it handles changing a state of a system. Then, when something initiates a change, or expresses an intent, the DDD part has to make up a decision whether to change or to reject. It is Ok then, if the decision cannot be made ...
2
One of the greatest promise of microservices is that you will have independently deployable services.
There is a lot forces which fights against this so you should make wise decisions when you introduce anything which is shared amongst different services (a static xml file, a library, a database, etc..)
Whenever you have shared library (for example that one, ...
-3
Aggregates ARE domain entities - domain entities that contain other entities, thereby modelling one or more conceptual relationships.
1
Confusion in the blog post
How is the Infrastructure layer supposed to get to these interfaces? From the looks of his Onion Architecture model, the flow of references look like this:
Infrastructure -> Application Services -> Domain Services
You are correct that there seems to be some confusion on the specific layers being used in the blog post ...
Top 50 recent answers are included
