Problem:
how to guide programmers to implement domain driven design and modular architectecture
Relevant technologies used:
As a programmer I am always inclined to prioritise technical detail and just making things work.
One of the techniques to prevent building monolithic code bases closed to expansion is constant refactoring.
An architecture trick I picked up from developing Domain Driven Design is to twick the questions I would usually ask myself when refactoring from a question about the domain instead of it being about the
In order to allow for paced development I learned that designing the Domain can be slow, as long as everyone agrees with the bigger picture and they work towards that goal.
Given that I decided to work on a goal given the techniques available with the technologies at hand. The architecture I used for php for refactoring a monolith looks something within these lines:
application
controllers[web-specific]
services
model
[bounded-contexts]
entities
interfaces[or contracts of the domain]
infrastructure
[bounded-contexts]
services
persistence
These generic lines can be followed in most languages, implementation and need for some of these parts however can be missed, in particular a react-native app could have little to no persistence needs to start with, but I would expect that to grow more important and ingrained in the domain model if fragments are used with the domain in mind.
As an extra when developing a react-native first code-base my lead question I like to ask when thinking about architecture is: how would a web app use this module ? . That is mainly due to the ability to swap presentation components from react native to react and get a web experience out of the same underlying logic.
While doing some research on the subject Microcosm came the closest in terms of best help in modeling the domain I could find.
Microcosm can come out as a candidate for replacing redux in an application, however microcosm has rules of Domain Driven Design ingrained and can be used just as an architecture example at times.
Their recommendation here might look like replacing redux, when building a relatively small app or just when starting that might be quite a fair assessment, I can see them work together, although redux might influence the architecture slightly as well.
One other big influence over your infrastructure will be How you separate your components , the guys at armory talk about 4 component types, some might discard some a couple types when in a domain that has different boundaries defined, I can see these services (I would still use service components or functions) growing big as well, so at times these 4 categories will make sense.
These tips on working with redux in Large Applications are still relevant. A correct use of the domain tools would keep separation between data objects, but the other tips are brilliant, at least to be aware of.
Given that, I hope I gave you something to think of, chew while developing or refactoring your next react native app.
Don't be shy to comment if you disagree or if you feel some of these views are completely out of wack.
Would appreciate any kind of feedback as this is an ongoing development.
Also published on: