I'm new to Domain Driven Design, and I'm reading a lot about it. I started a first implementation of what I consider to respect DDD principles.
But now, I'm wondering something : to define the sub domains and contexts, I started from well defined UI designs. They describe well every steps that take when you want to interact with the app.
Do you think it is a good start point (of course, I also got close from the domain experts) ? I mean, UI's define the Use Cases no ?
An example :
You have an administration panel, and from this panel, you can manage companies. So, I conclued that my sub-domain is Administration/ and one of its context is Company/.
So I end up with something like this :
src/
Administration/
Company/
Domain/
Command/
Ports
Is it poor designed Domain ?
I'd really like to have your opinions about this please.
Have a nice day.
------- edit ------
As #Luca Masera said, My example was a little bit too tiny.
So to give more example, I would have ended up with something like :
src/
Administration/
Company/
Domain/
Company.model
Employees.collection
Commands/
AddEmployeeToCompany.command
GetAllEmployeesForACompany.query
[...]
Employees/
Domain/
Commands/
[...]
FrontEnd/ <--- didn't really think about the naming yet
Contracts/
Domain/
Contract.model
CompanyId.id
Employee.model
Commands/
ChangeContractForEmployee.command
Actually I don't really understand, because you've made only a single sample, if you end up splitting the same domain on each ui area. What I know is that the ui defines the use cases, but how they are implemented should not define the design of the domain.
If you have an Administration and, for example, a Frontend, and you split the Company domain between the two, then the answer is no, it's not ok. The Company domain should have all its logic enclosed in a single package, not scattered around several context.
For example, in my last application I've to manage the user Absences. There're several types of them: holidays, maladies, exemptions and some others. I've also another concept, the Prospects: they cone from a sub-system and give general information for each type of Absence.
When the users starts the application, the first entry point is in the Prospects domain. The ui loads the page and then, with the help of Javascript and Ajax it asks a section of the page to each other domain. Every further interaction with the domain is managed by the ui (implemented in the infrastructure layer) of that domain.
--- After the editing ---
I would not do something like this. As I wrote before, in this way you end up splitting the domain logic in each macro area. Hence you loose all the advantages of the DDD.
I elaborate a bit more: what would you do when, later, in the Administration you need something about the Contracts?
Whatever architecture you use, you'll have:
src/
contracts/
infrastructure/
*** My way to manage the UI interactions ***
ui/
frontendA/ (it could be *hr_team*)
frontendB/ (it could be *managers*)
frontendC/ (it could be *employers)
application/
domain/
companies/
infrastructure/
*** My way to manage the UI interactions ***
ui/
frontendA/ (it could be *hr_team*)
frontendB/ (it could be *managers*)
*** no employers actions are planned ***
application/
domain/
Into the infrastructure you'll implement the Controllers that allow to interact with the Domain using the code inside the application layer. There're some overlapping here and there with the roles (some employers could be managers, some other part of the hr_team) but not with the functionalities.
In this way you still keep the logic of the domain (contracts) all together, but you end up with a nice splitting of the functionalities for each role.
Related
I have an assignment for school, where I have to create a domain model of a specific e-commerce site that delivers complete grocery bags to people's homes. (http://www.linasmatkasse.se/)
It's quite basic. Chose a bag, create account (with info), pay.
My question is, what exactly should be included in the model (in general)? In other words, where does the lines of the domain end? For instance, should delivery and suppliers be included? They aren't technically part of the website itself, by still play a role.
Thanks in advance!
What is domain
Let us take some theme/subject. It could be grocery delivery, satellites, swallows observations, anything. Let us name this theme "AAA"
domain model for AAA is a "profi IT" word for model for AAA. That's all.
All elements specific to AAA that you'll set in your model, belong to domain. I don't know, why the old good word theme is not used. It is a pity. But the term is already accepted.
So, delivery and suppliers are in your domain. And also much more specific words belonging to grocery. And to bags. And to people's homes - addresses, drive ways in and out - everything that is relevant to your theme.
The domain sets your vocabulary. And that one is really important - you should use the vocabulary used by your clients and not to invent new words, such as "domain" for "theme" :-)
And first you should define your Use case diagram, later- State machine diagram, Deployment diagram, Component diagram, Communication diagram, Sequence/Activity/Time/Interaction Overview diagrams, and at last - class, object and composite structure diagrams. You needn't make all of them, but SOME are necessary.
Every entity that models an entity in reality is a part of the domain. In your example, delivery and suppliers should be a part of the domain model. Basically any entity that has a defined behavior should be modeled as a part of the domain. Many times it seems like the domain model components aren't a part of the website and this is actually normal, the front-end is a way of viewing the domain model, it doesn't need to expose everything within the domain.
I usually find it easy to think about what entities are logical components of the business model in the real world and I only remove one if I find that it is redundant, unnecessary or can be encapsulated within another entity.
About the entities that are not the part of IT system
Do not ignore the pure human operations. On the contrary. Put them here, only their use cases will connect not actor-(sub)system, but actor-actor. And seeing them is very good for better planning the system as a whole. When ignoring them it is impossible to create a system good for user. The IT system is an integral component of the larger system, and we are creating the larger one really, with planning the support, processes, exchange of info, divisions and dependencies.
Too often had I problems with programmers who are blind to anything out of IT system border. And often it is impossible to make them think out of these borders. As a result, the system is blind to the real needs of the user, too. So we have that sad picture of user-hating software.
It is very useful to start to study the problem/domain/theme from entities that are out of the IT system, and to create firstly the diagram, that considers IT system as merely one of many blocks.
We are attempting to use DDD techniques on my current project and have started going through the process of domain modeling and are experience a lot of friction around "how to" create the Domain Model. I haven't found a lot of examples our guidance on this topic.
We have started by attempting to define the Ubiquitous Language by talking to the business users and coming up with a list of domain entities and their attributes. That's going pretty well but we are having problems with things like:
Behaviors, actions
Permissions
Business Logic (if attributeA = true then foo else bar)
I have a lot of ideas on how we could capture all of these various things (sequence diagrams, uses cases, flow charts, ect...) but if there was a formal process or some resources providing example driven guidance it'd definitely speed things up a good bit.
This is a great question.
One of the first steps I always take is to have a meeting with one (yes one) domain expert and have an open discussion about the problem domain from their perspective. I bring plenty of post-it notes and make sure I have plenty of whiteboard space. As the expert speaks I try to draw a flow or BPMN diagram on the wall using the post-its. I find it's very important to give the domain expert something visual to look at - something which he/she can physically point at and say "no, that's wrong!" (which they usually do, many times).
During these conversations I am listening closely to what the expert is saying and asking for clarification where there is ambiguity. I always find that it's better to let the ubiquitous language emerge naturally this way - rather than trying to forcefully establish it (I would never ask a domain expert to give me a list of terms).
I try to express the flow diagram in terms of commands and events - even if I do not end up using CQRS I find this naturally flows into more concrete requirements. When the flow diagram is complete (I can usually tell this because the the expert looks very pleased with it - there's a good chance he/she has never seen the domain mapped out this way and they are often thrilled by the novelty), I start to trace individual routes through the flow diagram. Often these individual routes can be easily expressed as behavioural specifications in terms of Given, When, Then style requirements. (see BDD section 3)
Once you have a collection of Given, When, Thens which cover every route through the flow diagram, you have sufficient specification to start the design phase of a domain model in exactly one Bounded Context.
I repeat the process with other domain experts. With subsequent experts I also listen for correlation between the language and terms they use. Most times different domain experts will share terms in the ubiquitous language, but will mean slightly different things. This is a sign that we are dealing with distinct bounded contexts.
I'll admit that I am still quite a newbie with DDD and even more so with CQRS. I also realize that DDD and/or CQRS might not be the right approach to every problem. Nevertheless, I like the principals but have some questions in the context of a current project.
The solution is a simulator that generates performance data based on the current configuration. Administrators can create and modify the specifications for simulations. Testers set some environmental conditions and run the simulator. The results are captured, aggregated and reported.
The solution consists of 3 component areas each with their own use-cases, domain logic and supporting data structure. As a result, a modular designed seems appealing as a way to segregate logic and separate concerns.
The first area would be the administrative aspect which allows users to create and modify the specifications. This would be a CRUD heavy 'module'.
The second area would be for executing the simulations. The domain model would be similar to the first area but optimized for executing the simulation as opposed to providing a convenient model for editing.
The third area is reporting.
From this I believe that I have three Bounding Contexts, yes? I have three clear entry points into the application, three sets of domain logic and three different data models to support the domain logic.
My first instinct is to follow these lines and create three modules (assemblies) that encapsulate the domain layer for each area. Should I also have three separate databases? Maybe more than three to support write versus read?
I gather this may be preferred for CQRS but am not sure how to go about it. It appears to me that CQRS suggests a set of back-end processes that move data around. But if that's the case, and data persistence is cross-cutting (as DDD suggests), then doesn't my data access code need awareness of all of the domain objects? If so, then is there a benefit to having separate modules?
Finally, something I failed to mention earlier is that specifications are considered 'drafts' until published, which makes then available for simulation. My PublishingService needs to have knowledge of the domain model for both the first and second areas so that when it responds to the SpecificationPublishedEvent, it can read the specification, translate the model and persist it for execution. This makes me think I don't have three bounding contexts after all. Or am I missing something in my analysis?
You may have a modular UI for this, but I don't see three separate domains in what you are describing necessarily.
First off, in CQRS reporting is not directly a domain model concern, it is a facet of the separated Read Model which takes on the responsibility of presenting the domain state optimized for reporting.
Second just because you have different things happening in the domain is not necessarily a reason to bound them away from each other. I'd take a read through the blue DDD book to get a bit better feel for what BCs look like.
I don't really understand your domain well enough but I'll try to give some general suggestions.
Start with where you talked about your PublishingService. I see a Specification aggregate root which takes a few commands that probably look like CreateNewSpecification, UpdateSpecification and PublishSpecification.
The events look similar and probably feel redundant: SpecificationCreated, SpecificationUpdated, SpecificationPublished. Which kind of sucks but a CRUD heavy model doesn't have very interesting behaviors. I'd also suggest finding an automated way to deal with model/schema changes on this aggregate which will be tedious if you don't use code generation, or handle the changes in a dynamic *emphasized text*way that doesn't require you to build new events each time.
Also you might just consider not using event sourcing for such an aggregate root since it is so CRUD heavy.
The second thing you describe seems to be about starting a simulation which will run based on a Specification and produce data during that simulation (I assume). An event driven architecture makes sense here to decouple updating the reporting data from the process that is producing the data. This has huge benefits if you are producing large amounts of data to process.
However it doesn't sound like a Simulation is necessarily the kind of AR that would benefit from Event Sourcing either. For a couple reasons:
Simulation really takes only one Command which is something like StartSimulation
Simulation then produces events over it's life-time which represent what is happening internally with the simulation
Simulation doesn't seem to ever receive any other Commands that could depend on the current state of the Simulation
Simulation is not interacted with by multiple clients/users simultaneously and as we pointed out it isn't really interacted with at all
In general, domain modeling is very specific to each individual project so it's hard to give you all the information you need to build your domain model. It will come as a result of spending a great deal of time trying to understand your user's needs and the problem they are trying to solve with the software. It likely will go through multiple refinements as you develop insights into their process.
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.
I've started learning about DDD and wanted to know how others have organised their projects.
I've started off by organising around my AggregateRoots:
MyApp.Domain (namespace for domain model)
MyApp.Domain.Product
- Product
- IProductService
- IProductRepository
- etc
MyApp.Domain.Comment
- Comment
- ICommentService
- ICommentRepository
- etc
MyApp.Infrastructure
- ...
MyApp.Repositories
- ProductRepository : IProductRepository
- etc
The problem i've bumped into with this is that i have to reference my domain product as MyApp.Domain.Product.Product or Product.Product. I also get a conflict with my linq data model for product....I have to use ugly lines of code to distiguish between the two such as MyApp.Domain.Product.Product and MyApp.Respoitories.Product.
I am really interested to see how others have organised their solutions for DDD...
I am using Visual Studio as my IDE.
Thanks alot.
I try to keep things very simple whenever I can, so usually something like this works for me:
Myapp.Domain - All domain specific classes share this namespace
Myapp.Data - Thin layer that abstracts the database from the domain.
Myapp.Application - All "support code", logging, shared utility code, service consumers etc
Myapp.Web - The web UI
So classes will be for example:
Myapp.Domain.Sales.Order
Myapp.Domain.Sales.Customer
Myapp.Domain.Pricelist
Myapp.Data.OrderManager
Myapp.Data.CustomerManager
Myapp.Application.Utils
Myapp.Application.CacheTools
Etc.
The idea I try to keep in mind as I go along is that the "domain" namespace is what captures the actual logic of the application. So what goes there is what you can talk to the "domain experts" (The dudes who will be using the application) about.
If I am coding something because of something that they have mentioned, it should be in the domain namespace, and whenever I code something that they have not mentioned (like logging, tracing errors etc) it should NOT be in the domain namespace.
Because of this I am also wary about making too complicated object hierarchies. Ideally a somewhat simplified drawing of the domain model should be intuitively understandable by non-coders.
To this end I don't normally start out by thinking about patterns in much detail. I try to model the domain as simple as I can get away with, following just standard object-oriented design guidelines. What needs to be an object? How are they related?
DDD in my mind is about handling complex software, but if your software is not itself very complex to begin with you could easily end up in a situation where the DDD way of doing things adds complexity rather than removes it.
Once you have a certain level of complexity in your model you will start to see how certain things should be organised, and then you will know which patterns to use, which classes are aggregates etc.
In my example, Myapp.Domain.Sales.Order would be an aggregate root in the sense that when it is instanced it will likely contain other objects, such as a customer object and collection of order lines, and you would only access the order lines for that particular order through the order object.
However, in order to keep things simple, I would not have a "master" object that only contains everything else and has no other purpose, so the order class will itself have values and properties that are useful in the application.
So I will reference things like:
Myapp.Domain.Sales.Order.TotalCost
Myapp.Domain.Sales.Order.OrderDate
Myapp.Domain.Sales.Order.Customer.PreferredInvoiceMethod
Myapp.Domain.Sales.Order.Customer.Address.Zip
etc.
I like having the domain in the root namespace of the application, in its own assembly:
Acme.Core.dll [root namespace: Acme]
This neatly represents the fact that the domain is in scope of all other portions of the application. (For more, see The Onion Architecture by Jeffrey Palermo).
Next, I have a data assembly (usually with NHibernate) that maps the domain objects to the database. This layer implements repository and service interfaces:
Acme.Data.dll [root namespace: Acme.Data]
Then, I have a presentation assembly declaring elements of my UI-pattern-of-choice:
Acme.Presentation.dll [root namespace: Acme.Presentation]
Finally, there is the UI project (assuming a web app here). This is where the composition of the elements in preceding layers takes place:
Acme.Web [root namespace: Acme.Web]
Although you're also a .Net developer, the Java implementation reference of the cargo app from DDD by Eric Evans and Citerus is a good resource.
In the doc'd code, you can see the DDD-organization into bounded contexts and aggregates in action, right in the Java packages.
Additionally, you might consider Billy McCafferty's Sharp Architecture. It's an ASP.Net MVC, NHibernate/Fluent NHibernate implementation that is built with DDD in mind.
Admittedly, you will still need to apply a folder/namespace solution to provide the contexts. But, couple the Evans approach with #Arch and you should be well on your way.
Let us know what you are going with. I am on the same path as well, and not far from you!
Happy coding,
Kurt Johnson
Your domain probably have a
name, so you should use this
name as namespace.
I usally put repository
implementation and data access
details in a namespace called
Persistance under the domain
namespace.
The application use its own name
as namespace.
I'd check out codecampserver since the setup there is quite common.
They have a core project in which they include both the application and domain layers. I.e. the insides of the onion (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/).
I actually like to break the core apart into separate projects to control the direction of dependency. So typically I have:
MyNamespace.SomethingWeb <-- multiple UIs
MyNamespace.ExtranetWeb <-- multiple UIs
MyNamespace.Application <-- Evans' application layer with classes like CustomerService
MyNamespace.Domain
MyNamespace.Domain.Model <-- entities
MyNamespace.Domain.Services <-- doman services
MyNamespace.Domain.Repositories
MyNamespace.Infrastructure <-- repo implementation etc.
MyNamespace.Common <-- A project which all other projects have a dependency to which has things like a Logger, Util classes, etc.