Tag Info

New answers tagged

0

I'd recommend being careful with the "can't exist without" rule. This talks to the concept of composition in UML/OO design and may have been one of the prescribed approaches to designing Aggregates in the original DDD blue book (not sure about that) but has largely been revised since. It might be a better idea to see your aggregates from a transactional ...


0

You could consider SOA if you want to. The thing is here you're only dealing with Commands. If you add the Publish/Subscribe pattern (message queues, service bus), you can have the serives publish events/messages, and not have to know who the subscribers were; the subscribers would all get the news and operate off the message contents.


0

tl;dr - break the rules if you need to. DDD can't solve all problems; in fact the object ideas it gives are good advice and a good start, but really bad choices for some business problems. Consider it a hint for how to do things. For the issue of loading all children (transaction) with the parent (account) - Looks like you've run into the n+1 problem ...


1

In addition to what Doc Brown mentioned regarding Bounded Contexts, you might want to consider that you're colluding two different events regarding the student. They enroll in a program, but the selection of a class does not flow through the program itself. That is, You have a ProgramEnrollment for a Student and there is a separate concept of a ...


2

Actually, you discovered what Fowler would probably call a Bounded Context - the idea of splitting one domain model into two different sub-models, one for the "class options" and one for the students' choices. Just take your third model as a blueprint for your database schema, and keep the other two models as part of the spec. Or try to draw some fences ...


1

My advice is to stop thinking about services, commands and fancy terms in OO design. I would strongly recommend modelling your business logic without thinking about service oriented architecture, how the data will be transferred from clients to the service, etc. You have an application. Your application clearly has two modules: Module for processing a ...


0

You have a good model for handling addresses. The country state(/province) relationship has worked well for me. I am not sure it works for all countries. For the applications I have worked with, I have been unable to normalize the city field. This results in three tables with cascading foreign key constraints. country state_province address Searching ...


0

This is an issue if you use an ORM to map your domain objects directly to the DB. This falls apart rather quickly for all but the most trivial of applications. Instead create separate classes to represent your data store and map those. You will need code that maps the BOs to the DTOs, but you will not be forced to compromise your domain classes to make ...


0

The suggested IsWithinSpec in Widget-Class knows too much implementation detail about the WidgetDescription-class, e.g. that it contains a MeasurementSpecification. A so called TrainWreck. You could instead create a method in WidgetDescription-class and delegate there. public class Widget { ... public Boolean IsWithinSpec() { return ...


2

I don't think they necessarily relate at all. DDD is about designing software from a business domain perspective, utilizing an ubiquitous language that you and your customer both understand. Many software developers mistake it for a programming technique, but it's more of a way to organize potential software structures (i.e. classes) around business domain ...


4

Eric Evans has said that DDD is just (one flavor of) good object-oriented design. He just wrote it down and gave it a catchy name. The two are not at odds, they are, in fact, one and the same.


1

Tiers and DDD are orthogonal concerns. Your tiers shouldn't care about the design of your objects. That would imply tight coupling, an undesirable attribute. In most tiered systems, there is some sort of data transfer object or data stream that is communicating information between the tiers. XML and JSON are common. Each tier has its own objects it ...


1

Disclaimer: I am "the person who wrote the accepted answer" to the other question. :o) In practice there are quite a few situations where in the same subdomain there might be multiple Bounded Contexts. Technology differences it might be a variation upon the legacy app mentioned above, but if we're developing a web and mobile version of the same ...


0

A little remark, and then a tentative answer. Use eventual consistency between aggregate's boundaries (before asking whose job it is) That's aggregate design by definition. We might argue whether this is a good or bad decision, but the Aggregate in Domain-Driven Design is a "unit of consistency". This is not to say that this is "the right way to do ...


0

My belief is that you can just send the response from the error handler or test the data before sending if possible. Can also use a preload step during app initialization from your REST interface and store valid value parameters and use those on your client to test data going out. It would be simple to try to send a response from your handler. Garbage ...


0

When you have a situation like this where two objects seem interdependent, sometimes the solution is to refactor a dependency into third object. In this case why don't you have WebinarVote object with propose(ChatRoom, Person) method? After the voting period is over, your Webinar (or whatever it is called now in your architecture) service object will ...


0

Firstly, congratulations on recognising that inheritance is a poor choice in this situation. You are 100% correct. Changing the type of an entity at run-time is definitely code smell! @Doc Brown's answer is getting to the heart of the matter, especially the comment about using Person rather than User, and allowing a 1:many between Person and roles. What is ...


0

One way is that we have an Inheritance Hierarchy of Users which each one has his own data and his own behaviors (for example in one clinic we have doctor, patient and Secretary that all of them are derived of the user.) That's IMHO not a good approach. You have persons (IMHO a better term than "users"), and "doctor", "patient", and "secretary" are ...


1

Why don't you separate the concepts? Have one bounded context to handle the user identity. This BC will have all data related to the person itself. This should answer "Who is that user?" Have another BC to control the roles which each user have. This BC will be responsible for answering "Is this user allowed to do that?" And a 3rd BC for the operations ...


1

Disclaimer: I'm not a DDD expert, but I'm going to do my best here to answer your questions. Let's use an Online Book Retailer as an example. A book seller is offering to sell books on his website, but he doesn't print the books himself. Instead, he has a long list of "Book Suppliers" who print and ship the books to his warehouse, were he packages them and ...


4

I think the business object/entities you are describing aren't actually domain objects in the DDD-sense, if you are applying DDD your business logic would be contained in the Domain Objects themselves; the entities you are describing (having business logic in a separate layer) seem to be Anemic. If you want to know whether to use DDD you would have to ...


0

A way to find instances by variable criteria, as suggested by scriptin's anwer is the right way. However, you don't necessarily need the full weight of the frameworks mentioned. I have recently programmed exactly what you described. The repository needs meta-information about the fields ob the object you are requesting - a config class is a good option, and ...


0

I think you may put it this way: in your specific case if the main purpose of the application / webservice / whatever you are developing is to make reports, then reporting tends to be considered a domain service. Otherwise it is an infrastructure service.



Top 50 recent answers are included