I have an array of Users and I need to know if the array contains only one User and if so, is that User a super user. For this, I think a Specification (isSatisifedBy) is perfect for this, however, where in my application should I save these files? in the bounded context under a Specification folder?
Thanks in advance
See this example made by Eric Evans in his famous book on DDD.
A specification is part of the domain model, so there should live in the same package of the model, so of course in the same bounded context.
In this example, Cargo is the model and RouteSpecification is one of its specification.
Related
I've started learning the principles of DDD and I'm currently trying to get a grasp of the concept of a bounded context. In particular, how do you decide just how big (or small) it has to be? Yeah, I know, as small as possible and as big as necessary (according to Vaughn Vernon).
Let's say I were to model a blog. I could then go and say there are 3 bounded contexts involved: 1) Front Page (featuring the most recent articles, no comments shown) 2) Discussion (a single article including comments) 3) Article Composer (where I compose an article).
However, this doesn't feel right (the ubiquitous language is the same for all of them), it seems as if I'm coming from a front end point of view and am still thinking in terms of view models or something.
Could anyone please point me in the right direction?
A blog is not a good example for use of multiple bounded context. It's not really a "big enough" software example to warrant their definitions. DDD & BC's are really aimed at big/complex enterprising software systems.
Like you say, the aggregates always have the same meaning in your 3 examples.
I gave this example of Bounded Context in a previous answer, which I hope explains BC's and when to use them: Bounded Contexts and Aggregate Roots
Try to look at your whole domain from different perspectives, as an editor of article, you probably will use sentences like creating a draft of an article, publishing an article, as an article a reader you will in example read article and comment on it. Alongside building your domain language you will identify entities and their behaviour, some of them will appear only in one perspective, some will appear in both, but you will distinct them by their behaviour. Your domain language shows you the boundries of each perspective, that you implement as a bounded contexts.
The best example I read by subdomains so far is the following.
Just examine the actual company! Each department taking part in the business process can have its own subdomain. In an ideal world each subdomain has its own bounded context in your implementation. You should ask yourself whether the company needs a new department to do this? Is it really that big?
The BC must be big enough to describe a department of a company. A typical example is a webshop, where you have a shopping core domain and invoicing, delivery and storage subdomains. Having multi-tenancy and so multiple aspects - as a previous answer described - is not enough. A blog with an author and a few readers does not require multiple departments, so you can solve this with a single bounded context. You can have multiple modules in your bounded context if you think you have medium size structures in your bounded context.
Eric Evan's DDD book, pg. 49:
Setting aside purely technical issues, each object in the design plays
a conceptual role described in domain model.
I think what author is saying is that all objects in the design ( besides predefined types such as int, string ... ) also exist as concepts in the domain. Wouldn't such assumption be wrong, since I would assume there may be objects in the design that don't exist in a domain model, but are instead used to help describe a domain object or implement its behavior?
thanks
I think whatever you need as help to describe a domain object or implement behavior would be a technical issue, which the author said to set aside.
Can you give an example of an object that is part of the domain design but is not a technical form of help and does not play a conceptual role in the domain model? If you can I would probably argue that it should not be part of the domain's design.
I have started reading few chapters of the blue book and have read the first three chapters of red book (Implementing Domain Driven Design). I have a two questions:
(1) Can a sub-domain have more than one bounded context? I am particularly looking at the example in Implementing Domain Driven Design book where there is a forecasting sub-domain sort of coupled/overlap with inventory. (Apologies if you have not read the book, but the idea is that there is a strong overlap between the two bounded contexts).
(2) How do I organize my project solution structure (I am using .net), are there any examples of real world projects that I can look at? Should I create folders namely sub-domain, core-domain, generic-domain and then specify the modules under it? I am struggling on how best to define my structure so that it shows the onion/hexagonal layers is in place.
Thanks in advance.
Yes. The Domain is composed from multiple sub domains (if it is complex enough) and each are in fact a group of bounded contexts. The Domain itself can be considered a bounded context (BC) from the app point of view.
A BC doesn't mean that it contains an unique model, but a specific representation of the business concept. So you can have a Book definition in multiple BC but in each, the definition is slightly different, ranging from full details to just an id. So the Book from Inventory is different than a Book from Sales for example. It matters how that BC understands a concept.
The resulting model is valid only in that BC, although it can have the same name as the model from another BC. But that's what namespaces are for.
There isn't a recipe for that, everyone structure their projects how they see fit. But most of the time you'll have at least one Domain project and UI, Persistence, Infrastrcuture projects. I think that the best structure depends on the app and on how the developers thinks so the way I do things might not be the optimum way for you. In a nutshell, structure the app as it makes sense for you.
When comming accross concepts within a Domain Model where there exists something that has a name and sounds like an object but overlaps with the responsiblility of one of the 5 main DDD building blocks what is the best practice for naming this object and or dealing with design which may or may not include that name or phrase in the actual implementation?
To give a more concrete example lets say that we are designing a time tracking application in the spirit of DDD and encounter something that the domain experts refer to as a "time log" which is supposed to be the log which holds punch-in and corresponding punch-out times for all employees.
With this information my initial thought is that if there were a class written called TimeLog which allowed for querying existing time entries and also for persisting new or amended time log entries that such a class is really playing the role of a DDD repository. For simplicity sake, lets assume that after various discussions and refactoring that we come to a conclusion that each time log entry is essentially it's own aggregate root and thus has the need for a corresponding repository.
Now we are left with the option of either naming our repository as TimeLog which seems more in line with the DDD concept of ubiquitous language or we could call it TimeLogEntryRepository which seems to fit the more general convention for naming Repositories after the Aggregate root that they query/persist. I'm leaning more towards the the idea of using TimeLog since it is more descriptive of the actual role that it plays in the domain model which should in turn help in communicating design to domain experts. The choice of using TimeLogEntryRepository on the other hand follows existing DDD conventions and thus would make the design easier to follow for developers. A compromise could also be to go with the TimeLog naming but to have all repositories implement an IRepository interface or inherit from a common Repository base class to help developers locate and distinguish repository classes from others that make up the domain model. The main concern I have with using a base class is that it may encourage the use of marker interfaces or a weak unnecessary base class just for the purpose of organization and not due to behavioral factors.
What is the best practice in cases like this? I can see the same type of issue perhaps happening for services as they are another piece of the typical DDD building blocks that developers typically name using a "Service" suffix such as in SomeComplexActivityService but for Entities and Value Objects this is really a non-issue. I'm especially interested to see what others may have to say that have more DDD experience under their belt.
I personally prefer TimeLog.
It's actually amazing how much easier it becomes once you switch focus to business instead of technology. Proper naming is main weapon to keep that focus sharp.
The same goes for services - instead of ApplicationRegistrationService, I use ApplicationRegistrator.
Here's quite nice article about repositories.
I second #Arnis L. suggestion. I would also add that in respect to DDD your domain should reflect the actual UL (Ubiquitous Language) which you share with business analysist and other people that are often non technical people. So I think that you will talk with them about TimeLog and not TimeLogEntryRepository. Repository is just a pattern and it's name should not be in the naming conventions.
If Book aggregates Chapter which in turn aggregates Page, then what should be the aggregate root? One possibility might be:
Book is an aggregate root with Chapter as a leaf and Chapter is an aggregate with Page as a leaf.
In this scenario, Chapter is a leaf in one aggregate and a root in another. Is this okay? Would it make sense in this scenario to have two repositories, one for Book and another for Chapter? If so, then couldn't the Chapter repository be used to circumvent the fact that access to Chapter should only happen via Book? What would be the best way to handle a situation like this?
In my opinion, the whole idea of aggregate roots make sense only when there is a single root for a given aggregate. Which one -- it depends on your requirements. Let's examine two possibilities:
Book is a root and it contains Chapters containing Pages. This design is useful when your usage scenarios all include interacting with books: users select books and apply their operations/commands on whole books. Notice, that the Book aggregate is in 'operations' layer of your domain model -- it, as a whole, represents concepts what part of are day-to-day business.
Chapter is the root. Is contains Pages. It also has reference to Book. This design is useful when usage scenarios focus on interacting with individual chapters. Chapter aggregate is in 'operations' layer now. Book forms an aggregate by itself but is is placed in 'potencial/capabilities' layer beneath the operations layer. This means that books are an asset to the organization, an enabler for the business, but are not part of day-to-day activities. Moreover, books don't know anything about being referenced by Chapters.
To sum up, all depends on specifics of you case, the requirements you have. Be aware that layers in the domain model ore primarily a business concept, not technical one -- they hep you to model the domain well. For further information please read Eric Evans' Domain-Driven Design, especially 'Large scale structure' part.