Yet here I am diving head first into learning this because 90% of what I read around Event Sourcing & CQRS assumes OOP, which isn’t what I’m finding out in practice. I’m glad my career with OOP ended before DDD became a thing. Need to communicate? Use JSON schema/protobuff. If you’re in an Elm front-end monolith, put in separate files.
![domain driven design java domain driven design java](https://miro.medium.com/max/1400/1*SWwk7pJM1cww4GZcRNPUsA.png)
That means Aggregate, Service, Repository, and Factory are now just functions you compose together in a bigger function (that’s a good thing, it’s called railway or pipeline programming).īounded context isn’t an OOP/FP thing, that’s a monolith vs. But if you remove stateful objects, then you’re just left with functions. Understanding the different types of users, the words they use, and making that strong types. The Database on the back-end, the Step Function in your infrastructure, the “ Model” in Elm front-ends.Ī lot of what I’m learning from researching DDD is the same thing the Agile crew uses Behavior Driven Design: learning the Business language, and modeling it into your code. (OOP people are thinking “dangerous”)Īlso, while “there is no state” in FP, there is always someone who stores your state. However, if you’re doing Event Sourcing or CQRS, hopefully you can see how your life just got a lot simpler. OOP: Eventually, when the state of the business changes (a change that matters to business experts), you’ll publish Domain Events to communicate the change.įP: A function will get an input and return a value.Ĭaveat with the above is F# and Scala do have classes and you can map your mental model of DDD around the boundaries. OOP: If a business logic doesn’t belong to a given object, you’ll define Services that will manipulate the involved elements.įP: Objects don’t have state or methods you just create new functions return that return new values. Complexity just grows into more functions. OOP: If an object is too complex for a single class, you’ll create Aggregates that will bind Entities & Value Objects under the same root.įP: There are no classes, only functions that return immutable Types and Unions. OOP: You create them with the help of Factories.
![domain driven design java domain driven design java](https://res.cloudinary.com/practicaldev/image/fetch/s--P_QZ-LB2--/c_imagga_scale,f_auto,fl_progressive,h_900,q_auto,w_1600/https://dev-to-uploads.s3.amazonaws.com/i/hs5ao1ytk5795hh70ljq.png)
![domain driven design java domain driven design java](http://static.odrotbohm.de/lectures/ddd-and-spring/images/bounded-context1.png)
You can’t store them as there is no state.
![domain driven design java domain driven design java](https://miro.medium.com/max/1838/1*UrAwPlb9omtPw6bBG6IHrg.jpeg)
OOP: You use Repositories to retrieve and store them.įP: You use functions to retrieve them. Everything is immutable so has an implied ID, but you can add if you wish. OOP: You model your business using Entities (the ID matters) and Value Objects (the values matter).įP: You model your business using Types, Aliases, and Unions. Here’s a paragraph summary of the 500 page book I’ve translated each sentence into typed FP. Attempting again to learn Domain Driven Design, and it’s clear if you’re an Object Oriented Programmer trying to learn Functional Programming, no wonder you’re confused.