New answers tagged

-1

Most typically Validation of data types is the responsibility of the anti corruption component; for instance, in a shopping cart, the quantity of an item is expected to be a counting number. So the anti corruption component would take the quantity count out of the message, and create a Quantity value that enforces that rule. That will sometimes be done in ...


1

This is not all too different from what you would get in a web application: a big form that is logically split up could be sent to the server in one go so you would get all the data in a single 'DTO' (the request itself). The best way to go about this is indeed split the data from the DTO into commands that have a logical grouping of the data. For example, ...


3

You might want to have a look at the concept of Task-Based UI. Under that paradigm, not only do the back-end layers reflect your domain processes, but the front end is also built with the end user's ultimate business goal in mind. There might not be a 1-to-1 mapping between user tasks and domain operations 100% of the time, but this is in any case a big ...


-1

The way you're describing the changes as business operations is often employed with event sourcing, but of course you don't need to do event sourcing to follow the advice. The question then is why you want to use it - do you just intend to store an audit trail? Or do you just don't like the Object->DTO->DB approach and would prefer Changed ...


0

So if I understand correctly the difference between the 2 solutions is really just in serving the 1st page if the external API is down: solution 1 is serving a generic (thus potentially useless) page solution 2 is serving a customized page (but with potentially stale cached info) Both solutions will fail subsequent requests if the external API remains ...


0

public class Customer { public int Id { get; set ; } public int SocialInsuranceNumber { get; set ; } public bool IsValid() { // my logic to validate social insurance number } } First, avoid creating invalid objects. It only makes the code harder to maintain. If Customer is an object in your domain model, then it shouldn't be ...


0

If my domain has several Bounded Contexts, but only ONE team will work on all contexts, should I develop an Ubiquitous language for each context? or should I have only one and force to into all contexts? Changing the spelling of this question slightly; if your domain has several Bounded Contexts, but only ONE team will implement all of them... ...then ...


1

Given this lack of behaviour, does a DDD approach make sense? Is the problem that you are trying to solve part of the core of the business? Do you derive a competitive advantage here? If it really is "just a query tool," then no. If maintaining the quality and integrity of the data isn't critical to success, then no. DDD is too expensive a hammer ...


1

The domain model is exposing commands and queries that can be used by the application. So the application (more specifically, the "anti-corruption component") is responsible for taking the DTOs and re-expressing them in a form that the domain understands. If you are building your application from the domain model out, this is really straight forward: your ...


2

You may want to display the inventory level on the web page, or you may want to display the edition number of the inventory in stock (imagine your inventory is books, magazines etc). This information comes from the Inventory domain. The main thing to notice at this point is that you are talking about a view, which is to say that using stale data is ...


0

From my point of view there are different defintions of "Product" - every bounding-context hast its own definition of "product"-domain : In the Content-Management-Bounding-Context a product has an image and a description text. In the Inventory-Bounding-Context a product has stock-quantities, product seller, forcasts when the product will be availabile In ...


1

I think your question really calls for 2 orthogonal sets of options - Do you load two objects and present their data together or do you load 1 object that contains everything you want ? Do you use aggregates for displaying stuff, or something else ? If you believe in the CQRS approach, it turns out that aggregates may not be the best bet for reads. Each ...


0

DDD is meant for applications where business logic is complex. "print something" is not a complex business logic. It is actually not a business logic at all. If, the business logic in one context needs some information to properly handle some use case, then that information is part of that context. So the idea that one bounded context might need ...


0

So, I think what the OP has done is create 2 Aggregate Roots called ActiveCustomer and InactiveCustomer, and in those has added a property of type Customer. This is an entity, which represents a Customer in his system. This is where I think the confusion/issue has arisen. Effectively this has made the aggregate root a wrapper around the entity, but it ...


0

TL;DR: you are over thinking this. However, I had fun overthinking it along with you. So buckle up.... Single responsibility ( reason to change ) of an entity should be to uniquely identify itself, in other words, its responsibility is to be findable. No, that's not right. The single responsibility of an entity is continuity. Identity is an ...


0

Important question: in the first example, where does the code that enforces the business invariant live? The first approach looks simple and straight forward, because all the hard stuff has been moved somewhere else! So, in order: public User { public IList<Order> Orders { get; set; } } This is bad, because the constraint on the list of users ...


0

I have some trouble coming up with a way to expose domain model in a resource-oriented manner. You shouldn't be exposing the domain model in a resource oriented manner. You should be exposing the application in a resource oriented manner. if the UI is more command-oriented, which often is the case, then we'll have to map between commands and ...


0

we can't have duplicate Category names either, that would just cause confusing and redundancy. Assuming that you have a business invariant that requires no duplicate category names, then the responsibility for enforcing that invariant belongs in some aggregate. Since enforcing the rule requires having access to all of the category names currently in ...


2

Project.addDocument is the right approach. The guiding principle is the definition of an aggregate. AGGREGATE A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate, designated as the root. A set of consistency rules applies within the aggregate's ...


4

I think the answer to what you are trying to achieve is how to identify bounded contexts. An aggregate on its own can indeed by thought of as a consistency boundary for all entities and value objects enclosed with in. However, you don't expose your entities directly to the outside world. To apply DDD effectively start by identifying your sub-domains. Find ...


0

data provided by an user is somehow incorrect and could cause my domain object to get into invalid state. So a subclass of DomainException extends RuntimeException is thrown. Perfect. Now: how should I handle this? Suppose my endpoint is used by a frontend and I want to display a proper message to user. Catch the runtime exception at the fault ...


1

Is it possible to just directly query ORM to get UI/Report data? It is usually the most efficient way. If you do need some sophisticated business logic to be involved in reporting because of current big gap between db and required data set - well, you might consider saving some redundant stuff when your command results persist or even run report data ...


0

Validation is part of your business logic, your domain, it ensures the state of your domain never becomes invalid, so when you persist it, the data that is saved is always valid. Good domain model highlights encapsulation and is such, which never becomes invalid, it has checks on operations which may break its valid state (be it raising exceptions or simply ...


0

Validation rules are business logic. Even a simple "NULL" check is a business rule -- someone decided it was OK for "Middle Name" to be missed but "County" must always be filled in. Most validation rules are not that simple and may even require access to external services e.g. "is the guy on the credit agencies s**t list". So forget about Validation as a ...


0

First of all, if you have a Account aggregate, and a Customer aggregate, and the business rule for modifying an account by adding a Customer requires looking at the customer state and at the account state, then either your business rules or your model are wrong. The aggregate boundary is to include all of the state needed to enforce the business invariant. ...


0

So one aggregate is a ChatAggregate which allows people to add comments. However a user can only add one comment per hour or one comment for the entire life time. My domain object cannot keep all comments in memory but I still need my ChatAggregate to apply this business logic. Because of the eventually consistent nature of my view store, I cannot let my ...



Top 50 recent answers are included