Hello I have a question regarding ddd layers:
I basically structured my folders in:
├───presentations
│ ├───controllers
│ ├───helpers
│ ├───protocols
├───modules
│ ├───domain #interfaces of implemented command handler
│ ├───commands #Commands interfaces & abstract implementations
│ ├───errors #Errors & Error Types
│ ├───events #Events interfaces & abstract implementations
│ ├───services #services interfaces & abstract implementations
│ ├───infrastructure
│ ├───persistence #repositories implementations
but I have doubts about which layer I should create my use-cases, command handlers, commands implementations, events implementations.
my question is whether i should create in my modules / ** / infrastructure folder
or whether I should create a folder like:
├───DATA or APPLICATION
│ ├───dtos #Commands interfaces & abstract implementations
│ ├───commands #Commands interfaces & abstract implementations
│ ├───events #Events interfaces & abstract implementations
│ ├───useCases #services interfaces & abstract implementations
Another question: my presentation layer, should controllers be on that layer?
You can create a folder in ./modules/application and put your use cases there.
About where to put the command handlers, command implementations or events implementations should be in the infrastructure folder. Because probably they are going to be dependent of some infrastructure, like rabbitmq, or spring boot (if you are using java), or amazon SQS etc..
Yes, your controller folder should be inside the presentation, also if you have any CLI or Event controller that is triggered by outside.
Related
Let's say I have a bunch of integrations that uses to abstract modules: parser and ordering.
How would you say is the better approach for organizing the folder structure in a DDD point of view?
ordering/
----abstract.py
parser/
----abstract.py
integration1/
----ordering.py # depends on ordering.abstract
----parser.py # depends on parser.abstract
integration2/
----ordering.py # depends on ordering.abstract
----parser.py # depends on parser.abstract
OR
ordering/
----abstract.py
----integration1.py # depends on abstract
----integration2.py # depends on abstract
parser/
----abstract.py
----integration1.py # depends on abstract
----integration2.py # depends on abstract
The abstract files handles the business rules of my application (how we validate data, how we orchestrate the request-response cycle, etc.) and the integration files handles the business rules of the third parties (how we interpret the data they send, how we prepare the data in a way they expect, etc.).
The way I see, each integration acts as some sort of repository which it's core implementation relies on abstract.py.
I'm inclined for the first approach since we clearly separate these domains, but at the same time all files have the same purpose.
What are your thoughts?
You have two problems here: using abstractions in the domain layer and integrating external contexts.
Abstractions in the domain layer
The abstract files handles the business rules of my application (how we validate data, how we orchestrate the request-response cycle, etc.)
Constituting the domain layer (or package) only of abstractions (i.e. interfaces in other languages, you need to find the Python analogue for it) of its dependencies and injecting their concrete implementations from different packages is a good practice. That keeps the domain layer independent of infrastructures. There is an architectural pattern promoting this practice called the port and adapter architecture. Your first proposal somewhat connotes this pattern.
Additionally, in DDD, most of the business rules are enforced by the primary constructs: aggregate roots (the most prominent entities in the domain), entities, and value objects. All of these are implemented as concrete types, no need to abstract them away. Dependencies like repositories, domain services, etc. are abstracted.
Here follows a potential directory scheme, open to modifications of course, respecting the conventions I mentioned:
.
../domain
..../model
....../entity1
....../value object 1
....../entity2
..../services
....../service1 (interface)
....../service2 (interface)
..../repositories
....../repository1 (interface)
....../repository2 (interface)
../port
..../adapter
....../services
......../service1 (concrete)
......../service2 (concrete)
....../repositories
......../repository1 (concrete)
......../repository2 (concrete)
Integrating external contexts
... and the integration files handles the business rules of the third parties (how we interpret the data they send, how we prepare the data in a way they expect, etc.)
Integrating external contexts (context mapping in DDD terminology) itself is a challenge. The strategic part of DDD deals with this issue and recommends several options for integrating contexts depending on the nature of the relationship between them. All the options strive to ensure that communication with external contexts go through some translation process; external contexts must not infiltrate unchecked.
The way I see, each integration acts as some sort of repository which it's core implementation relies on abstract.py.
In DDD, repository is meant to retrieve and modify aggregate roots. Some of your translations do fit well into the repository pattern and you can model them after it. However, some of them may fit better into domain services. Just as any other repositories and domain services, you may put the abstractions of the integration ones in the domain package and their implementation in a different one.
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.
I defined my software system using EA. I stayed mainly at the high level so far. The software interfaces between my components are represented as Structural Elements "Provided Interface" (the little purple bullets) and "Required Interface" (the little sockets).
Now, I would like to go a little bit further into the details, and define the API corresponding to each of these Provided Interfaces, ideally as a class diagram. It would be perfect if I were able to create a nested composite structure diagram for each of these Provided Interfaces, like for software components for example. But it seems that EA does not enable that.
What I do is that I create an Interface nested in my software component, then I link the Required Interface (the purple bullet) to my Interface (purple square) with a Dependency link. Then I can create a nested composite structure diagram in my Interface. But I doubt this is the optimal method.
Can someone tell me what is the "EA-approved" way of defining Required Interfaces ?
Thank you :)
You can directly select the Interface in the ProvidedInterface or RequiredInterface without needing to explicitly create a Realize or Dependency connector to the target interface.
You can do this as shown in the figures below:
One advantage of this is that you do not have to show the actual target interface on the same diagram as the components while still being able to navigate to them. This becomes handy when you have components that provide or require many interfaces (and you do not want to clutter your diagram). With this approach you can use the Find | Locate Classifier in Project Browser context menu and directly jump to the composite diagram.
Background
We were designing a micro-service to manage bookings in our system. So we decided to solve this using state-machine abstraction, i.e Bookings can be in one of multiple states, and can be transitioned to another through some actions/events.
We had a very healthy discussions between me and my colleague and I had some different opinion about how the state machine should be designed.
I took an example of REDUX, where we have different ACTIONS (EVENTS + PAYLOAD) and based on ACTION.TYPE we transition our system to another STATE.
This was fairly simple but my friend introduced confusing factor like ACTIONS and EVENTS: two complete different things (which in my opinion should be same in any state-machine)
And he is arguing that EVENTS cause some ACTIONS to perform on a state-machine to transition to some another STATE. And his point is EVENTS & ACTIONS are two complete different aspects and should not be same. They have different points and implications.
For e.g Certain EVENT may be CREATE_REQUEST , but actually looking for availability and making a booking is a ACTION derived by CREATE_REQUEST event.
But I completely disagree and I am strongly saying an ACTION should be something like [CREATE_REQUEST, {DATES, ...OTHER_INFO}] and the machine should perform accordingly and transitioned to some other STATE .
so what should be the correct approach.
├── src
| ├── ACTIONS
| ├────── CREATE_REQUEST // return {TYPE: CREATE_REQUEST, {data}}
| ├────── DECLINE_REQUEST //return {TYPE: DECLINE_REQUEST, {id}}
| ├── STATES
| ├────── DRAFT
| ├────── PENDING
| ├────── REQUESTED
| ├────── COMPLETE
I am waiting for some expert suggestions and advice so that we can have a clear vision on what to do.
The action represents what the user interacts with. The event is how your application deals with said interactions. It is wise to implement an arbitration layer in most cases, depending on the size of the project. Once you are convinced of the importance of the architecture of the application you should implement events handling the user actions. You simply don't want to put all your business logic into the actions. Doing so is a surefire way to making the code unmaintainable.
In Rhapsody, is it possible to draw a diagram like the following?
I can add ports and interfaces to classes, but Rhapsody doesn't seem to support the port concept for components.
Yes it is possible, but for Classes. Usage is possible in normal Class or Object Diagrams.
see:
IBM Manual "Managing Ports"
A "Component" in Rhapsody is different to an UML Component,
it represents a Executable or Library and therefore there is no special Component Diagram like your Example.