Modular system architecture

I'm trying to implement modularity in my POS system to allow 3rd parties to do some kind of modules/plugins/add ons. I have started implementing a SPI and an API, my question is: the access to the data on database has to be by this way or I need to provide a Service?

At this point you may have noticed that I have few experience in this, so any advice in this topic is well

Edit: A little more information. My system has an user's system theorically checking credentials to access any part of the system, mysql database, is written in Java. 开发者_如何学运维My modules securely need access to some tables in the DB, access to main menu, I don't know what else I can say, but my question is more about abstractedly how an api need be.

thanks in advance

PS Sorry if my english is bad

Octavio Ruiz

---

In general terms, software systems are (usually) broken up into "layers" (such as the User Interface (UI), Business Logic (BL), Data Access Layer (DAL) and so on). These layers also provide natural places to integrate with. So...

the access to the data on database has to be by this way or I need to provide a Service?

From what you've said I would think other systems should integrate via a service, or API. Giving direct access to the database means that they'll side-step the Business Logic that should apply to the interactions they want to perform. In your specific case it will probably also mean they'll side-step your security measures.

Modularity

There is two parts to this:

• Architectural styles and design patterns which assist modular systems (specifcially regarding maintenance and extensibility); these are all technology agnostic (it doesn't matter what technology you're using).
• Implementation and technology specific frameworks and techniques.

Design Patterns

Wikipedia is a great place to get an introduction into patterns, and StackOverflow has lots of great content around them too.

I's start off getitng to grips with what's known as SOLID, although it's all useful I think you'll find the S, O, I and D areas of most value.

Dependency Inversion (the "D") is going to be particularly relevant to you as far as modularity goes. By creating a "contract" via an interface, you create something that other parties can build on - for example: they can swap out your "default" implementation with one they have made.

Technology Specific

I can't speak specifically for Java (although it should be easy for you to find out) but .Net has a few frameworks that are specifically built for this kind of thing, e.g: the Managed Extensibility Framework (MEF).

The point is that most technology stacks will offer various frameworks, tools and approaches for building modular systems.