21–30 of 73 posts
DDD would be a good addition to that list. Domain Driven Design made functional would be my recommendation for those wanting to look into it.
DDD is completely orthogonal to software architecture.
I don't think the term "Microkernel Architecture" should be used in this context. I think "Modular Architecture," (or Plug-in like is mentioned) gets closer to this extension-based pattern. The reason being that there's no relevance to the kernel, and modular kernels, also take this approach with replaceable plug-ins or extensions.
"Modular Architecture" is more broad in my opinion and rather a description of internal structure. A "modular monolith" for example is modular but doesn't necessarily have a "core" nor is it required to be extensible with plugins by users.
What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…
If you use an ORM (such as Entity Framework I'm about to mention but there are lots) for the write/mutation part then the ORM provides you with that disconnect. You might want to use a different mapper for read, that allows you to write efficient SQL that meets particular needs.
For example, a few years back in .NET Framework I swapped a system that designed/built on Sql Server to run on Postgres. Took me a few days. I didn't change any domain logic during that time. I'd say that the ORM provided a disconnect between the actual persistence and my domain.
I do like a disconnect between my API and the database so that I am able to update the database without causing issues with consumers of my API. That usually requires some kind of mapping but only once. My preferred model right now is a CQRS (don't need ES) using Paramore's Brighter command pattern.
That's for an RDBMS, I think with schemaless/DocDB you can go even further but then the code that loads out the data needs to deal with missing values. That's a different sort of constraint.
I hope that helps, I think I'm rambling now.
They are better explained here: https://www.oreilly.com/content/software-architecture-patter...
There's also the full-blown book version at https://www.oreilly.com/library/view/fundamentals-of-softwar...
What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…
But everyone is telling me it's a bad idea, so I'm really not sure. A more convenient way to copy properties over would be nice.
What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…
I'm building an application in this fashion at the moment in Go, and honestly, I think it's kinda painful. At some point I already merged the persistence with the domain model, so it's just the domain model with SQL related struct tags. I am tempted to merge it with the HTTP model as well, add JSON tags to it. But everyone is telling me it's a bad idea, so I'm really not sure. A more convenient way to copy properties…
If you add a property which shouldn't be public you have to separate them. For example in the domain model you have a user with email but do not want to expose the email.
Second argument: I usually create a simple struct for each method. For example I do not want, that they provide the id for post requests. I want to send the id on get requests so that they can send an update request with the id. I prefer only "non-null" arguments and as a bonus you get a clean (auto-generated) api documentation.
What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…
Depends what "disconnected" means. Before Object Relational Mappers came along, you wrote a load of SQL in Stored Procs or in some other framework. This was super tight coupling because updating the database version could ruin everything. Not everything was in compiled code, so it was hard to track. If you use an ORM (such as Entity Framework I'm about to mention but there are lots) for the write/mutation part then t…
What I nerver understood: * How to disconnect the domain model from persistence. Some solutions add the OR Annotations to the domain model. Some other map the domain model to persistence with a Mapper-layer. But all of them have some constraints. For e.g. on a web api I receive a dto, map it to a domain model, map it to a persistence model and vice versa. Not much gained imho. In this example I would add the OR-annot…
Being disconnected enough so that V2, can load V1's persistence without too much pain is good. Again looking at you office.
Persistence and domain models are fraternal twins, not identical twins. In general recognize that domain model, and persistence model are different things that have slightly different needs. For example the domain model of a person might only care about age, the persistence model is only going to care about DOB. So yeah 95% of the time they are the same and nothing is gained from separating them but having them be too close is often the source of problems.