The COMPONENT file is used for the markup of the component setting up the core UI of your component. If your component needs a pick list, for instance, the component file is where you place the <select> tags.

The CONTROLLER file is where your JavaScript controller lives. This controller encapsulates the actions and logic your component uses. The standard interface for a Lightning Component controller is as shown here:

({
  customAction : function(comp, evt, helper) {
    //Your custom logic here
  }
})

As intercomponent communication occurs by firing events, your controller methods are often event handlers or event emitters. Emitter methods take the following general form and utilize the .fire() method to fire off the event:

customEmitter : function(cmp, event, helper) { 
var myObj = cmp.get("v.myObj"); 
var myEvent = $A.get("e.namespace:someEvent");
myEvent.setParams({ "myObj": myObj}).fire();
}

Note the use of the $A global variable. This is your access to the Aura object. It provides a number of utility and access methods including the .get() method, which functions similarly to the jQuery selector system. Using get you can access application wide events.

The HELPER file exists to contain helper methods that can be reused in multiple places throughout the component. Specifically, it helps you write logic that is passed by reference to both controllers and renderers. This allows you to keep your renderers and controllers relatively clean, easy to read, and minimizes duplicate logic. For instance, if you have code that calls back to an Apex controller and you need to access it from both your controller and renderer, you can place that code inside the helper and reference it from both using helper.commonMethod:

// Your controller 
callApexController: function(cmp, helper) {
  helper.hCallApexController ();
}

// Your renderer 
afterRender: function(cmp, helper) {
   this.superAfterRender();
   helper.hCallApexController ();
} 

// Your helper
hCallApexController: function(cmp, helper) {
var a = component.get("c.getS1Data"); 
a.setCallback(this, function(action) { 
if (a.getState() === "SUCCESS") {
	//handle the data returned 
} else {
//handle the error
} 
});

   $A.enqueueAction(a);
}

In the preceding example, we extracted the logic for calling an Apex controller method and handling the results to the helper file. We can use that logic easily by calling helper.hCallApexController(). Aside from promoting reusability, this helps us ensure that when we fix bugs related to our Apex callout, there is only one place to fix them! Also, take note of the naming convention I used for the helper method. You don't have to preface your helper methods with h but adopting a logical and consistent naming convention allows your teammates and your future self to easily know that this method is not defined later in the controller, but in the helper file.

In our preceding example code, you saw references to both a controller and a renderer. We have not discussed renderers yet because you don't need to worry about creating a customer renderer generally. In fact, you only need to create or edit the renderer if you need to modify the way the standard renderer works. When overriding or customizing the renderer, ensure that you always call this.superRender(); first. Once you've done that, you can include custom logic or even call helper methods like the example does.

Renderers provide a place for you to override the standard render methods. This allows you to, for instance, trigger logic when a particular render method runs. For instance, look at this simple re-render override:

rerender : function(cmp, helper){
    this.superRerender();
    helper.disableSubmitButton(cmp);
}

In this case, the component that will fire rerender automatically whenever a component attribute is modified will fire this custom version, rather than the default rerender method. Our custom rerender method does two things. First, it calls the main rerender method, as triggered by this.superRerender(); and then calls our helper.disableSubmitButton(); method. This effectively allows us to call custom logic (in this case, our disableSubmitButton logic), whenever one of the standard render methods is called (in this case, the rerender method). Disabling a submit button or other UI-based properties is perfect for this sort of automatically chained logic.

So when do you need your own render object? You'll need a custom renderer if, for example, you want to update a component whenever a second component is changed. In that case, your second component's renderer would call a helper method to update the first component.

The STLYE file contains all the CSS needed to style your component as you see fit. This is, perhaps, the most straightforward of the component's files. There is really only one thing that differentiates this CSS file from the numerous others you've worked on in the past. The scaffolding for the style file is as follows:

.THIS {
}

The .THIS tag is the essential difference. When your component is utilized, the framework dynamically replaces the .THIS element with the component's instance name. This allows you to override styles for your component without stepping on another component's identically named .awesomeDiv style. In other words, if you have two instances of a custom button component, the framework will automatically replace the .THIS element with the instance name of each component. That way, the styling of one instance won't interfere or overwrite the styling of the second instance. For example, if you programmatically change one component's .THIS styling, the second instance of that component is not affected!

The DOCUMENTATION file is where all of the utilization documentation for your component goes. While this is, I believe, primarily for components based on AppExchange to write packaged documentation for their components, as application developers, we should never forget to take every opportunity to document design decisions, tradeoffs, and assumptions. Eventually, even the most well-written software exhibits bugs, and the better written the code is, the harder it can be to decipher after months or years of writing it. Use the documentation file to help your future self and your team! Also note, that you can access the full documentation of your org's Lightning components by visiting the auradocs application in your org—AuraDocs at https://<Instance> lightning.force.com/auradocs. Keep in mind, however, that if you've not written documentation for your custom components, it won't be visible in the auradocs app.

The DESIGN file can be a bit hard to understand. In a way, it's a header file for your component. Like C header files, the design file describes the methods, attributes, and events your component exposes so that the Lightning App Builder and other visual tools can properly guide the user in using your component. For instance, you might expose an attribute in a design file like this:

<design:component>
    <design:attribute name="Customer" label="Customer" description="Customer contact Id you wish to interact with" />
</design:component>

In this design file, we enabled a single attribute named Customer. This will be displayed in the Lightning App Builder with the Customer label and the description will be Customer Contact ID you wish to interact with. These label and description parameters help end users who are creating applications with your components to see what data to pass in.

Lastly, but certainly important is the svg file. This file contains the SVG data of your components icon. Even if you are not developing your component for distribution, you should provide an icon to help distinguish it from other components in the Lightning App Builder.

public class LAccountController {
    @AuraEnabled
    public static List<Account> getAccountsWithBillingAddress() {
        return [SELECT Name, Id, BillingAddress FROM Account Order 
By Id Limit 20];
    }
}

<aura:component controller="Namesapce.LAccountController">
 <!-- component details -->
</aura:component>