New answers tagged

0

The concepts you mention (Clients, Products, Orders, Billing) are typically represented in a single Domain Model and hence Bounded Context. I suggest you are understanding these concepts incorrectly.


2

If your different bounded contexts understand the meaning/purpose of a country differently, then you need to model it appropriately different in each one. However, if we are speaking simply of reference data of ISO codes and names, then I believe it's pretty fair and standard to stash it wherever is convenient and make it accessible to all interested ...


2

From your questions, I think you misunderstand bounded context. You may want to reread Chapter 14 of the blue book. Trying to answer generally - you have to be careful about sharing concepts between two different bounded contexts. After all, part of the reason that the boundary exists is that the ubiquitous language changes. To assume that the same data ...


2

By exposing Services you are exposing your business. You should not expose your database. Even if Service just implement the very same methods that repository does. It's also a way to grant access to the data to certain set of components. These components are also key components for the transaction management. By exposing the interface instead of the ...


0

Admittedly, the DDD book doesn't make it very clear, but when it says "stateless" it means "without persistent or long-lived state". So, service objects are allowed to keep state in their instance variables/fields, as long as it's not state that gets persisted or externalized in some way. The state the book cares about, when discussing statefullness, is the ...


1

What you're facing here is the tension between two issues: good encapsulation and the Single Responsibility Principle. If Party has to expose its inner state to everyone, it's poorly encapsulated with all the usual effects that has (in this case, that includes violating Tell, Don't Ask). But if it keeps its state encapsulated then only it has the access ...


1

Why does a Role have a direct relation to Service, when the relation obviously requires a Claim to exist? Just forget about that one. Respectively where is there a relation between Service and Team? Add an indirection via an Ownership entity to model that. Choosing Team and Service as the only root aggregates is correct. Team 1 <-> * Role Role ...


4

Matthias Verraes describes domain events as follows (highlight added): Domain Events are a special type of Event messages. A Domain Event is something that has happened in the past, that is of interest to the business. This last distinction means we separate all technical concerns from the domain. Usually, the distinction is very clear. In other ...


2

"Should the Party class know how to send itself to the client, and repository?" It is hard to answer your question because you are writing your application in a procedural rather than object-oriented style, despite the object-oriented and domain-driven-design tags. In an object-oriented program your Party object would constrain the number of Pokemons ...


0

Your problem domain model includes your domain business rules. Business rules are constraints on the elements of the model. They mean that an elevator doesn't move with the door open, that perishable goods aren't loaded into a non-refrigerated container, and that a cancelled order isn't shipped. That doesn't mean that when your domain interacts with ...


1

Learn to model a simple problem into a problem domain model and then into code. Your first four requirements all relate to books. Your final "Manage users" is vague, so I'll leave that for now. How do you represent a Book? Assuming each book is unique, you model it with TWO objects. One being a particular book (Book), and the other the set of all books ...


0

Should the Party class know how to send itself to the client, and repository? I would suggest it shouldn't know about either of those. Your Party object represents something in your domain model, so it shouldn't really need to know about networking. Similarly if your repository is used to store Party objects then the Party shouldn't know anything ...


4

First of all, domain in domain-driven design (DDD further on) does not mean you divide your application into layers, which are only responsible for specific operations. Domain in DDD is the layer which contains your business rules and which is completely ignorat of anything else in the app. Be it persistence or presentation, the domain should not care how it ...


1

To me, repositories, combined with ORM or other DB persistence layers, have these disadvantages: Covering up Units of Work. UoW have to be coded by the programmer and can rarely be implemented as a kind of magic in the background, where the user simply makes queries and modifications, without defining the UoW boundaries and possibly the commit point. ...


3

Does this kind of validation lives in the domain or application layer? Application. The magic search term you want is anti corruption layer Typically, the message received by your application will be some flavor of DTO. Your anti corruption layer will typically create value types that the domain will recognize. The actual command dispatched to the ...


0

Conceptually: Event is something what happened. The past cannot be changed. Command is something to do. Command may not happen (may be rejected). We can only change our future state by executing another command (Compensate Action) which should result in Events changing state of the application. To "de-confuse" the question, think about this phrase ...


0

Would specific state make model entity invalid? If yes, then the model must prevent the entity from getting to that state. That means the model must know how to validate itself. But there is a slight problem : model validation often happens too late. Often, we want to do validation early, so user doesn't have to wait too long. That is why validation is ...



Top 50 recent answers are included