CODEWITHSUNDEEP
architectureumldomain-driven-designsoftware-design
John Gkikas
John Gkikas

Reputation: 33

How much can business logic be separated from frameworks/technologies?

Recently I have been rethinking of various ways to refactor older projects of mine, making sure to have a proper design first and applying the architecture into the code. The business logic of an application is supposed to be agnostic of data persistence implementation, presentation frameworks, technology and even (ideally) programming language. My question is, how do you deal with a use case/requirement where it seems like it is very tightly coupled to specific technology?

In my example, I want to have current sensor values, from a microcontroller, viewed on my browser. It is possible to implement this by having values stored in the database, read them and send them over to the presentation layer. However there is another way which is seemingly faster, and sounds more reasonable. By using websockets the server relays the values to the browser, and the server itself receives those values from the microcontroller through a stream.

These two approaches require almost entirely different design. The first requires a repository pattern that communicates with the persistence layer, where as the second one does not. The data flow is also different for the use cases. So two different implementations that fulfill the same requirement, require different architecture solely because of choice of technology and framework.

Is it still possible to design the architecture in a way that is not coupled to one of the two implementations?

Upvotes: 1

Views: 750

Answers (2)

guillaume31
guillaume31

Reputation: 14080

Is it still possible to design the architecture in a way that is not coupled to one of the two implementations?

To some extent, yes - by inverting the dependency between the bit of code that gets the data from the sensor and the one that makes it possible to see it on screen, i.e. by making the former unaware of the latter. A couple of options could be:

  • Plug the microcontroller input stream to a pipeline composed with the Chain of responsibility / Handler patterns. One handler can save the metrics to a database and another can send out the data via websockets.

  • Adopt an event-driven approach. Emit events corresponding to incoming metrics from the sensor and subscribe to them. Subscribers can do a variety of things such as saving the data to a database or sending it through websockets.

Of course, the part of the architecture charged with covering the "last mile" to the browser will always be different because scenario #1 is a pull-based approach from the client's part and #2 is a push by the server (web sockets). Chances are though that if you want to display pseudo-real time data, in scenario 1 you'll have to emulate #2 with some sort of polling.

Upvotes: 1

Geert Bellekens
Geert Bellekens

Reputation: 13784

It is perfectly possible to describe the functional requirements and business logic in an implementation agnostic way.

Most often this is done using Use Cases and use case scenarios.
Note that use case scenarios are not specified in UML, but they are a de-facto standard in the industry.

The idea is that your use cases represent large(ish) blocks of functionality offered by the application. It focuses on the added value for the user (actor) and not on the way it is implemented.

Typical things to avoid in use case analyses at this level is specifying things like:

  • the user click the "Details" button
  • the system gets the details from the database and shows in them in the detail window

But rather use phrases such as:

  • the user asks to get the details
  • the systems shows the details

This makes the analysis independent of design choices such as using a button, or a menu, or a function key etc..

The architecture on the other hand is usually more bound to a specific implementation (pattern), although it can still be independent of the actual technology used.

Upvotes: 0

Related Questions