Tag Info

New answers tagged

1

Event storage Event storage will depend on your application but it is a lot easier if you use a flexible storage for your events (so a NoSQL DB, JSON or XML). How you deal with updates will depend on several factors you need to take into account such as requirements for availability and timeframes for updates, amount of events, etc... Update your events ...


0

It depends on your concrete repositories, but generally speaking, I would add a service layer on top of the repositories. Depending on your repository implementation, they might be specific to your persistence store. It makes testing easier as well and leads to a hexagonal architecture, instead of a classic layered architecture (which I consider a benefit), ...


1

Yes, the service layer is an overhead if you don't have any business logic there. Layered architecture looks like an overhead when a layer (in your case service) is not doing much. But a layered architecture provides your loose coupling which is generally good for adapting requirements in future. If you can guarantee that you will never need to do anything ...


1

To complete Doc's response, events are not meant to return values, this would be a violation of the CQS pattern (separation of commands and queries, aka read/write). They capture business intentions, creating a kind of audit trail for all that happen in the system. They can be the only data source in the system. In that case, there may be no need to have a ...


2

Those two things do not much have in common, except the fact that also in the Service Layer pattern some kind of "events" may be involved. But that is where commonalities end. in the "Service Layer pattern", there are different layers calling each other and triggering some system change. But the calls are not necessarily "captured in event objects", nor ...


0

Both Have a central controlled table with: ID int PK Code varchar Then let app have table with: ID PK FK to central add as many flag columns as they want This way you still have one column for Code Another option is an app table CountryID FlagID Value This way your columns become rows Problem you have here is rewrite a lot of queries


4

The answer may be simpler than you might have originally thought: replace the "Countries" table shared across monolithic database-centric apps with a microservice, or simple webservice that exposes the same functionality with a simple REST call (note: I'm suggesting REST though that is not your only option, though it is probably the lightest-weight option). ...



Top 50 recent answers are included