Discover and read the best of Twitter Threads about #DomainDrivenDesign
Most recents (6)
The missing Ruby on Rails architecture
🧵let me explain the 10 rules here
🧵let me explain the 10 rules here
1. App layer vs domain layer
Assume that controllers and service objects are app layer (a bit simplification here, but bear with me).
Service objects can never call each other. They are the application facade.
Assume that controllers and service objects are app layer (a bit simplification here, but bear with me).
Service objects can never call each other. They are the application facade.
2. App layer modularisation is based on what "apps" you have
Usually you have some public facing app, admin panel, mobile API, some integrations.
Those are good candidates for "modules" at the app layer. Don't confuse it with domain layer.
Usually you have some public facing app, admin panel, mobile API, some integrations.
Those are good candidates for "modules" at the app layer. Don't confuse it with domain layer.
1/ We have been debating with some colleagues about the importance of learning about our decisions within the organization, and how the fast rotation of talent that's happening lately is affecting the decision-making outcomes quality.
2/ Here we had the supposition that the feedback cycle between a decision is made and understanding the consequences are long enough. We always thrive for fast feedback loops, yet we acknowledge that that's not always possible.
3/ It's not the same doing TDD within a unit test - feedback cycle of seconds-minutes vs a business decision and go-to-market strategy that can take months.
We are talking about the latter. Where those business learnings are most valuable for the organization
We are talking about the latter. Where those business learnings are most valuable for the organization
Excited to publish the first MVP version of contextive.tech for (@code)!
Contextive helps team use a #domaindrivendesign Ubiquitous Language by storing definitions and usage examples of terms in a yml file in their repo, and surfacing the definitions in handy places.
Contextive helps team use a #domaindrivendesign Ubiquitous Language by storing definitions and usage examples of terms in a yml file in their repo, and surfacing the definitions in handy places.
It works in any file, in any programming language - so you get the same hover definitions in a markdown document, a yml file, a code comment, a class or variable name - truly Ubiquitous. #vscode #domaindriven
All the terms are also added to the Intellisense autocomplete, so you can be confident you're using the right words for your domain.
object oriented programming is where you design each element in your code, based on rules around making well-formed classes and objects; we say domain driven design, based on "modeling the domain", is oop done right:
basically that means - solving the right problem
basically that means - solving the right problem
domain driven design produces higher quality software; it's about #domainModeling
which is basically #understandingTheProblem that the users want solved
which is basically #understandingTheProblem that the users want solved
3/3 cus who wants to go to work to hack away at some code that's not even solving the right problem
#objectOrientedProgramming #domainDrivenDesign #domainModeling #softwareDesign #codeNewbies
#objectOrientedProgramming #domainDrivenDesign #domainModeling #softwareDesign #codeNewbies
one way to look at it is that #domainDrivenDesign is the union of technical #objectOrientedDesign tightly coupled with subject matter expertise, business analysis and modeling. #ddd is #ood with soul. #ddDesign is #ooDesign done right
in complex systems, or enterprise development
different people/teams may have different
povs/ models/ experiences/ conceptualization/ understandings
of the subject matter or problem to be solved, and ...
👇🏾
different people/teams may have different
povs/ models/ experiences/ conceptualization/ understandings
of the subject matter or problem to be solved, and ...
👇🏾
they dont realize that there are these different povs; and even if they do,
they dont see the danger of coding to different concepts as long as it "works"; so inevitably ...
👇🏾
they dont see the danger of coding to different concepts as long as it "works"; so inevitably ...
👇🏾
#DomainDrivenDesign is not aggregates, event sourcing, CQRS, event storming etc. These are instruments. They have been shown to be very useful in DDD-minded projects. But we must be careful not confuse the Instrument with the Art.
To me, this is the key insight of DDD: When battling complexity in large systems, how project teams acquire domain knowledge, how they build, evolve and pervasively apply conceptual models, and how they protect the integrity of these models over time trumps technology.
DDD is about lifting the technology veil and seeing more fundamental forces at work in large software projects. DDD gives us a conceptual framework (domain models, bounded contexts, core domains, context maps) to map out and navigate the often hidden shoals of complexity.
