Seeking insights on DDD architecture in a functional programming context
heya folks wanted to get some input/insight around DDD architecture in an effect world. coming from a very OOP heavy perspective im tryin to get my head around the how, where and why of functional DDD. granted ive just sat down to a playlist by none other than the man Scott Wlaschin himself which should either help or further confuse but its progress. My typical folder structure for any bounded context within a ddd project is as follows. for example, i have a bounded context for Procurements that deals with supplier agreements, onboarding, etc. Theres elements of hexagonal design, cqrs, etc. ive always liked the clear (albeit verbose) separation. however the further down the effect rabbithole i go im starting to see the possibilities of overlap in the below folder structure without actually sacrificing context or readability. Essentially i think im just trying to start a conversation around how others are navigating the DDD world with an effect compass...
Similar Threads
Was this page helpful?
