Tag Info

New answers tagged

4

Updated. Clarifications taken into account. Looks like this is a multiple choice domain, which usually has the following requirements a question must have at least two choices so that you could choose among there must be at least one correct choice there should not be a choice without a question Based on the above [A] can't ensure the invariant from ...


1

I would go either [C] or [E]. First, why not A and B? I don't want my Question be responsible for creating any related value. Imagine if Question has many other value objects - would you put create method for every one? Or if there are some complex aggregates, the same case. Why not [D]? Because it is opposite to what we have in nature. We first do create ...


1

In case where requirements are so simple, that multiple possible solutions exist, then KISS principle should be followed. In your case, that would be option E. There is also case of creating code that expresses something, that it should not. For example tying creation of Answers to Question (A and B) or giving Answer reference to Question (C and D) add some ...


0

Why don't you create a service holding a collection of all categories? Then you can do validation very easy. An example: class BlogCategoryService { private List<Category> _categories = new List<Category>(); public void AddCategory(string categoryName) { if (_categories.Any(c => c.Name == categoryName)) throw ...


1

Never assume your inability to imagine why someone would WANT to do something has any correlation as to what someone else WILL do. Remember Murphy's Law, and ask "is there ANY situation where not being able to recognize distinct objects as equal will cause problems". If the answer is yes, the few lines of code needed to compare equality by value will be ...


1

I just can't imagine why I would have two customer objects representing the same customer Not all objects represent "customers". Other objects represent other kind of entities. In those cases a value equality could be more or less useful according to bussines rules, allowing to be able to check whether or not a given object passed as a parameter is ...


1

business logic should be in the model, otherwise you just have property bags What is business logic? Business logic is, that your object knows it's state and could answer questions like order.IsDistributed or order.IsQualityAssuranceDone or the like. It is no business logic, if you ask the question is this order already in the database. That is a ...


0

Q:How do we create objects? A: Using Domain Factories! Since the creation of a category contains complex logic (we need to validate uniqueness), we will utilize a domain factory to create the object for us. Inside that factory I'll use a UniqueCategoryNameValidator service that calls into the data-store (a DB in ur case) and check if the category is ...


2

I would create a domain service responsible for validating the uniqueness of the category. In my solution domain defines the interface of the service, infrastructural part implements it using a database. Please also take a look at http://stackoverflow.com/questions/516615/validation-in-a-domain-driven-design.


0

You have two competing demands, and I think you need to choose which of them you want to win. Demand 1, to have a fixed record of the state in each event. Useful for quick auditing by scanning the raw messages Demand 2, to have a record of the changes applied in each event, to facilitate event sourcing. Those two demands seem only subtly different, why ...


-1

I don't see any DDD's special requirements in this case, you can model mailing and billing addresses as person's properties and still store them in a separate table, for example: Person + MailingAddress : Address + BillingAddress : Address or Person + MailingAddressID + MailingAddress : Address + BillingAddressID + BillingAddress : Address


2

DDD does not enforce DB schema at all. The value object may be implemented as a group of columns, db entity (your third solution) or simply in a denormalized form if you can use document-oriented database for instance. It depends on different circumstances what is the best option to go with. Keep in mind that DB is only a tool for persisting your domain ...


0

I've built several DDD models, persistence was handled by NHibernate. We went with a repository pattern in our early projects and built all of our queries into our repositories. This is a great idea in theory but what we learnt in practice is that you end up writing a lot of boiler place when implementing the repositories and also they were practically ...


0

One approach is to separate your query model (the model that displays data) from your command model (the model that changes data). This is referred to as CQS, Command Query Separation. From an article describing CQS The concept of applying CQS at an architectural level says, our Domain and transactional operations will use the Repositories, but for ...


4

You already gave the answer yourself in your comment to the other question: If two Prefix objects with the same content are interchangeable, then Prefix is (probably) a value object. Another rule of thumb is: "Domain first, infrastructure second", i.e., don't let infrastructure concerns (here: primary keys in database tables) influence your domain model.


-1

I thought the difference was the linkage with the database. So an Entity object has state that maintains its place in the DB, whereas a value object simply contains the data. Writing the object back to the DB ends up as a update call in both cases, however the entity will use the internally-held key to refer back to the DB row, whereas the value object ...


0

There is a big difference between the application layer and the presentation layer from a DDD view point. Although DDD centers around how to model the domain using the DDD building blocks and concepts such as bounded contexts, Ubiquitous language and so, it is still vital to clearly identify and separate the various layers in your app. The architecture ...


1

The domain layer models the business of your application. This should be your clear interpretation of it's rules, it's component dynamics and contains it's state at any given moment. The application layer is "worried about" defining the jobs needed to be done to accomplish a certain application task. Mainly, it is responsible for mandate the necessary ...



Top 50 recent answers are included